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ABSTRACT 


PANSAT  is  a  small,  ^read-spectrum,  communications  satellite  under  design  at  the 
Naval  Postgraduate  Sdiool.  It  will  sui^rt  a  store  and  forward  bulletin  board  system  for 
use  by  the  amateur  radio  community.  The  flight  software  is  re^nsible  for  the 
autonomous  telemetry  collection  and  hardware  control  operatimis  of  the  satellite, 
omnmunkations  and  file  transfer  protocols  allowing  access  to  the  bulletin  board  system, 
and  command  interpretation  and  re^nse  to  ground  control  commands. 

In  this  thesis,  the  complete  flight  software  architecture  and  module  interfaces  are 
qiecified  using  the  Estelle  Formal  Description  Technique.  The  module  bodies  dealing 
with  communications  and  file  transfer  protocols  are  specified  in  detail  in  Estelle.  The 
current  design  goals  for  the  remainder  of  the  flight  software  modules  are  discussed. 
Appoidices  include  the  preliminary  flight  software  specification  itself,  a  data  flow 
diagram  interpretation  of  the  specification,  and  a  summary  of  the  Estelle  syntax  used. 
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SYMBOL  TABLE 


SYMBOL 

1  WHERE  USED 

1  MEANING 

bold 

diesis  and  specification 

A  Pascal  or  Estdle  reserved  word. 

italics 

thesis  and  qiedficatitm 

A  qiecification  constant,  including  a 
member  of  an  enumerated  type. 

thesis  and  specificatitMi 

Module  name  or  state  name. 

B^inning_Caps 

diesis  and  specification 

Name  of  a  user  defined  type. 

’single_quotes’ 

thesis 

Name  of  a  variable  or  record  field  in 
the  specification,  or  the  contmits  of  a 
variable  or  record  field. 

OxNN 

thesis  and  specification 

A  hexadecimal  number.  ”N”  stands 
for  the  digits  0  through  F. 

udiar 

thesis  and  specification 
(primitive  <bta  type) 

"Unsigned  character":  8  bits  of 
binary  data,  a  1  byte  unsigned 
int^er,  or  1  ascii  character. 

uint 

thesis  and  specification 
(primitive  data  type) 

"Unsigned  integer":  16  bits  of 
binary  data,  a  2  byte  unsigned 
int^er,  or  2  ascii  characters. 

ulong 

thesis  and  spedficatimi 
(primitive  ^ta  type) 

"Unsigned  long  integer":  32  bits  of 
binary  data,  a  4  byte  unsigned 
int^er,  or  4  ascii  characters. 

int 

thesis  and  specification 
(primitive  data  type) 

"Integer":  a  signed  integer. 
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1.  INTRODUCTION 


A.  PANSAT 

The  Petite  Amateur  Itevy  Satdlite  (PANSAT)  is  a  small,  ejqmrimental, 
omnmumcations  satellite  currently  being  designed  and  constructed  at  the  Naval 
Pos^raduate  SdKxd  (NPS)  and  scheduled  to  be  launched  from  the  spact  shuttle  in  1996. 
The  saldlite  will  use  half-duplex,  qnead-sytectrum  cmnmunicatimis  and  will  support  a 
stme  and  forward  bultetin  board  system  for  use  by  the  amateur  "HAM"  radio 
community.  PANSAT  will  operate  autonomously  in  the  performance  of  many  of  its 
functions,  whik  also  carrying  out  commands  issued  by  the  ground  control  statirm  located 
in  Monter^,  CA  at  NPS. 

B.  GOALS  OF  IHE  FUGHT  SOFTWARE 

The  flight  software  will  control  tiie  autonomous  operation  of  the  satellite,  allow 
amateur  radio  operators  access  to  the  onboard  bulletin  board  or  "mailbox”  system,  and 
provide  the  means  for  tiie  satdlite  to  le^xxid  to  commands  from  the  ground  ccmtrol 
station.  The  major  functional  areas  of  the  flight  software  are  listed  in  Table  1.1.  There 
are  otiier  software  functions  adiich  are  equally  important  to  the  PANSAT  project,  but 
outade  the  scope  of  tiie  flight  software.  These  include  the  "bootstrap"  software  which 
will  ormtrd  initial  configuration  of  tiie  satdlite  systems  upon  launch  or  rdxwt,  "client" 


ground  station  software  finr  use  by  the  amateur  radio  ccmimunity,  and  "commanding' 
software  for  the  ground  control  station. 


TABLE  1.1  FUNCTIONAL  AREAS  OF  THE  FUGHT  SOFTWARE 

1.  CommunicaticMis  Protocols  for  Anuueur  Radio  User  Access  and  File  Transfer 

2.  Telemetry  Gathering  and  Storage 

3.  Control  of  Satellite  Hardware  Systems 

4.  Command  Interpretation  and  Response  to  NPS  Ground  Station  Control 

C.  SCOPE  OF  THIS  THESIS 

This  thesis  is  the  result  of  the  initial  attempt  at  specification  of  the  flight  software 
for  PANSAT.  The  hardware  systems  are  still  evolving,  which  means  that  hardware 
control,  command  interpretation,  and  telemetry  gathering  requirements  are  still  being 
defined.  The  only  requirements  which  can  be  completely  defined  this  early  and  remain 
essentially  unchanged,  regardless  of  the  final  hardware  configuration  of  the  satellite,  are 
the  communications  protocol  and  mail  handling  functions.  For  this  reason,  the  actual 
preliminary  software  specification,  which  can  be  found  in  Appendix  A,  concentrates  on 
the  mailbox  system  and  the  transfer  protocols  for  uploading  and  downloading  files.  The 
prdiminary  architecture  for  the  remaining  software  modules  is  sketched  out,  and 
interfaces  have  been  defined  between  all  modules. 


Some  existing  third  party  software,  designed  q)ecificaUy  for  communications 
satellites,  will  be  used  aboard  PANSAT  to  su|^rt  the  applications  software  bang 
developed  at  NFS.  The  commercial  software  used  will  be  introduced  in  Chapter  n.  A 
PANSAT  file  header  has  been  developed  to  assist  in  proper  maintenance  of  the  mail 
stcnage  system.  The  elements  of  this  file  header  will  be  explained  in  Clu4>ter  m. 
Cluqiter  IV  will  discuss  the  qiecification  language,  Estelle,  in  which  Appendix  A  is 
written.  Chapters  V  through  Vm  will  explain  the  functionality  of  the  software  modules 
which  have  received  the  most  attention  in  Appoidix  A,  those  dealing  with  file  transfer 
and  mailbox  control.  Chapter  DC  will  introduce  the  preliminary  goals  for  the  remainder 
of  the  flight  software,  which  has  yet  to  be  specified  in  detail.  Chapter  X  will  cmitain 
cfMiclusions  and  recommendations  for  further  work.  Appendix  B  contains  a  grs^hical 
interpretation  of  the  specification  in  Appendix  A.  This  interpretation  uses  data  flow 
diagrams  which  provide  a  visual  means  of  identifying  the  software  architecture  and 
module  intnfaces.  Appoidix  C  will  provide  some  details  of  the  syntax  of  Estelle. 
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n.  THIRD  PARTY  SOFTWARE 


A.  SfACE  CRAFT  OPERATING  SYSTEM 

The  nte  oi  DOS  (Diac  Opoatiiig  System)  cm  a  personal  oompata  is  filled  by 
SCOS  ^ipaoe  Craft  Operatiiig  System)  on  oonqwter  aboard  PANSAT.  SCOS  is  a 
real  time,  multi-tasIdQg,  operational  environment  designed  ^mcifically  fcv  tiie  needs  of 
a  small  satdiite.(Ref.  1]  It  supports  apidicatiors  written  in  the  *C”  programming 
language,  and  many  of  the  primitive  ftinctims  familiar  to  *C"  programmers  are 
available  tiuough  tiie  Space  Craft  Opmting  System.  These  include  file  management 
opabOities,  dynamic  memory  allocaticm,  bit  and  byte  manipulations,  and  logical  and 
mathematical  operations.  Within  the  SCC^  opmting  environment,  the  various  modules 
whidi  make  up  the  flight  software  are  running  as  concurrent  processes,  able  to  pass  data 
among  tiiemselves.  They  are  put  to  "sleq>”  when  they  are  not  needed,  saving  CPU  time, 
and  are  "woken  up”  again  whenever  thdr  services  are  required. 

B.  BAX 

1.  AX^ 

AX.25  is  a  variant  of  the  CCITT  X.2S  link>laym  protocol,  and  is  designed 
to  provide  rdiable  data  tran^mrt  betwem  two  signaling  terminals.  [Refs.  2,  3]  This 
aqm^ronous  data  transfer  jnotocol  is  currently  in  wide  use  by  the  amateur  radio 
oommtmity  for  padcet  communic^ons,  and  has  thus  been  selected  for  use  in 
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ocMnminiications  with  PANSAT.  To  incorporate  AX.2S  functionality  into  the 
ccMnmiinkations  software  aboard  PANSAT,  a  {Mogram  called  BAX  is  nnployed. 

BAX  is  the  BekTek  corporation’s  implementation  of  the  AX.25  protocol.  It 
is  designed  to  wmic  with  the  Space  Craft  Opoating  System.  Because  of  the  availability 
of  the  BAX  software,  the  actual  functionality  of  the  AX.25  protocol  is  tran^Kuoit  to  the 
qjfdications  programs  developed  for  the  satellite.  The  software  designer  and  programmer 
need  only  consult  the  BAX  manual  [Ref.  4]  to  discover  how  to  access  the  csynbilities 
required.  For  the  amateur  radio  operator,  tlus  AX.25  protocol  is  normally  implemented 
by  a  inece  of  dedicated  hardware  known  as  a  TNC  (terminal  node  controller),  or  by 
software  contained  in  a  PC  (personal  computer)  based  system. 

2.  BAX  Application  Programs 

In  order  to  utilize  the  capabilities  of  BAX,  a  "BAX  plication”  program 
must  be  written.  In  the  PANSAT  flight  software  q^ification,  the  prinuny  BAX 
application  is  known  as  the  DATA_TRANSFER  module  (see  Chapter  V).  Other 
modules,  sudi  as  GROUND_CONTROL,  may  also  access  the  services  of  BAX. 

BAX  has  the  capability  of  receiving  frames  addressed  to  various  applications 
which  are  distinguished  ftom  each  cHher  by  having  different  ssid’s  (subsystem 
identification  numbers).  PANSAT  will  be  addressed  by  a  muld-charactm:  Amateur  Radio 
Callsign,  "PANSAT”,  for  example.  This  callsign  may  be  modified  by  use  of  ssid’s  to 
access  different  functions  aboard  the  satellite.  For  instance,  the  data  transfer  module  will 
have  ssid  ’1’,  and  the  HAMs  will  send  thdr  mail  to  "PANSAT-l”.  The  command 
intopreter,  GROUND_CONTROL,  may  have  ssid  ’2’,  so  that  commands  from  the  NPS 
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giQiaid  Httkm  ooiikl  be  sent  Oeie  direct y  by  BAX  without  having  to  be  in  die  same 
fbnnat  as  that  lecogniied  by  the  bulletin  board  system. 

BAX  ocrnimunkates  directly  with  tte  hardware  drives  which  operate  the 
radio  equqmient  on  the  satellite.  As  incoming  frames  are  received,  BAX  handles  all  of 
die  AX.2S  protocol  requirements,  and  notifies  the  appropriate  ai^licadon  module  of  the 
receqit  and  die  source  of  each  transmission.  In  the  case  of  the  data  transfo  module,  the 
frames  passed  to  it  by  BAX  must  be  assembled  into  the  packets  required  at  the  next 
higher  {Kotocol  level.  This  is  the  level  of  the  PACKEr_TRANSFER  modules  described 
in  Chapters  VI  and  vn.  When  the  data  transfer  module  receives  a  packet  from  a  packet 
transfer  module  for  transmission  to  a  ground  user,  the  data  transfer  module  breaks  the 
data  into  frames  which  i*.  passes  "down”  to  BAX  for  transmission  in  accordance  with  the 
AX.25  protocol. 

3.  BAX  F^nctioiis 

The  accessing  of  most  BAX  functions  by  PANSAT  application  modules  is 
represented  in  the  software  q^ficadon  as  messages  being  passed  through  an 
Abstract_Bax_Channel.  In  fact-  in  the  specification  model,  all  communication  between 
modules  is  accomplished  via  "channels",  each  channel  having  certain  types  of  messages 
defined  which  can  be  passed  through  it.  These  channel  and  message  definitions  form  the 
interface  qpecificatimi  between  software  modules  (see  Chs^ter  HI  and  Appendix  A).  The 
BAX  functfons  accessed  are  listed  and  briefly  explained  in  Table  2.1. 


1  TABLE  2.1  BAX  FUNCTIONS  | 

fVuctkm 

1  Purpose 

<^_input 

BAX  infcmns  PANSAT  iq)(dication  of  user  connection  request, 
user  disconnect,  or  incoming  data  frame. 

<)ax_claim 

PANSAT  ^ifrikation  tells  BAX  what  callsign  and  ssid  it  will  be 
using. 

PANSAT  application  passes  data  to  BAX  for  transmission. 

(pucjbusy 

PANSAT  application  informs  BAX  diat  it  is  "busy”  and  will  noi 
be  aooq;)ting  incoming  fnums. 

qaxjmbusy 

PANSAT  q)plication  informs  BAX  that  it  is  no  longer  "busy” 
and  will  once  again  accq)t  incoming  frames. 

qax_con_aq)t 

PANSAT  application  accepts  a  user  cnmection  request 

qax_oon_rg 

PANSAT  application  rgects  a  user  connection  request 

qax_oonnect 

PANSAT  Implication  sends  a  connection  request  to  ground  station 

qax_ui 

PANSAT  application  sends  an  unnumbered  information  frame  to 
a  ground  station. 

<puc_ 

^sconnect 

PANSAT  implication  disccmnects  from  a  ground  station. 

C.  FILE  TRANSFER  LEVEL  0 

File  Transfer  Level  0  (FTLO)  is  an  asynchronous  connected  mode  file  transfer 
protocol  devel(^)ed  by  Jeff  Ward  and  Harold  E.  Price  for  use  with  the  PACSATs  (pactet 
satellites).  In  a  connected  mode  protocol,  there  is  a  virtual  link  between  each  user  and 
the  satellite,  with  each  transmission  having  a  specific  destination.  This  is  in  contrast  to 
a  broadcast,  or  unconnected  mode  protocol,  in  which  communications  are  intended  to  be 
I»cked  up  by  anyone  listening. 


7 


Ac  inqtonentatkm  of  FTLO  is  cunentiy  available  to  amateur  radio  operaum  in  the 
form  of  die  program  "PO”  along  with  several  utility  programs  that  woric  along  with  it, 
such  as  "PHS"  and  "PFHADD".  Aldiough  the  qiecificaticm  for  FTLO  contains 
I»ovisi(ms  for  both  uploading  and  downloading  files  from  a  satellite,  only  the  uploading 
capabilities  are  implemented  by  the  currnit  vm^on  of  *PG”.  For  downloading  from  the 
satellites  whidi  currently  employ  FTLO,  die  nmi-ccMinected  mode,  "PACSAT  Broadcast 
Protocol"  [Ref.  5],  is  used.  This  is  implemented  by  the  program  "PB"  and  it’s  utilities. 

The  specificati(Mi  for  FTLO  [Ref.  6]  is  used  as  the  motivation  for  the  specification 
of  the  PACKET^TRANSFER  module  aboard  PaANSAT  (Chapters  VI  and  VII).  The 
qiiecification  of  the  packet  transfer  module  in  Appendix  A  is  much  more  detailed  than 
[Ref.  6],  in  an  attempt  to  show  how  the  protocol  will  actually  be  implemented  by  the 
software  aboard  the  satellite  at  the  lowest  possible  level.  The  PANSAT  implementation 
will  employ  an  FTLO-like  connected-mode  protocol  for  both  upload  and  download. 

An  effort  has  hero  made  to  remain  as  compatible  as  possible  with  any  other  FTLO 
implemrotation.  Some  of  the  specific  requirements  of  PANSAT  and  certain  design 
decisitms  have  led  to  some  variation  from  [Ref.  6].  As  source  code  for  "PG"  was  not 
available,  it  is  unknown  at  this  point  whether  that  software  will  actually  be  able  to 
communicate  with  PANSAT.  PANSAT-specific  ground  station  software,  capable  of 
communicating  with  the  packet  transfer  module  specified  here,  will  be  developed  by  NPS 
and  made  available  to  the  amateur  radio  community. 
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m.  THE  PANSAT  FILE  HEADER 


A.  FUNCTION 

JSafA  fite  maintained  in  die  mail  box  memory  of  the  satellite  must  begin  with  a 
PANSAT  file  header.  The  header  includes  information  such  as  the  file  numb^,  file 
name,  file  lengdi,  source  callsign,  destination  callsigns,  upload  time,  and  expiration  time. 
The  infosmatkxi  in  the  header  is  necessary  for  the  proper  maintenance  and  administration 
of  die  mail  box.  It  can  also  be  used  by  a  client  to  determine  which  files  onboard  the 
may  be  of  interest.  The  selectjand  makes  use  of  the  various  fields  of  the 
PANSAT  file  header  in  its  selection  criteria  (see  Chapter  VI). 

B.  STRUCTURE 

The  PANSAT  file  header  is  inspired  by,  but  is  not  the  same  as,  the  PACSAT  File 
fifeader  develqied  by  Jeff  Ward  dsid  Harold  Price  [Ref.  7].  It  is  arranged  as  a  variable 
length  array  of  unsigned  characters  (bytes).  The  fields  nearest  to  the  beginning  of  the 
header  have  fixed  positicms  and  fixed  lengths.  The  loigths  of  other  fields  are  qiecified 
within  the  header  itself,  causing  the  positions  of  the  later  fields  to  be  variable,  and 
dqiendant  on  the  fields  ahead  of  them. 

The  byte  portions,  field  names  and  fonnats  are  listed  in  Table  3.1.  Note  that 
positions  and  fidd  lengths  through  byte  41  are  fixed.  Each  of  the  fidds  "Destination  1" 
dirough  "Destination  7"  is  dthor  presoit,  with  a  fixed  loigth  of  6  bytes,  or  absent 
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cnqiileldy,  bued  iqxm  the  contents  of  the  "Number  of  Destinations"  Add.  The  fields 
"Hite*  and  "Keywtxrds”  have  variable  lengdi,  based  tqwn  the  contents  of  the  fields  "Title 
Lengdi"  and  "Keyword  Length",  reflectively.  The  column  Const  refers  to  the  constant 
name  given  to  the  associated  field  in  the  specificatitMi  of  Appendix  A. 


1  TABLE  3.1  PANSAT  FILE  HEADER  FIELDS  | 

ByteCsi) 

Const 

Name 

Format 

[0..1]  fixed 

ft 

Flag 

<0xBB>  <0x55  > 

[2.  .5]  fixed 

mn 

Mail  Number 

ulong 

[6.  .9]  fixed 

ml 

File  Length 

ulong 

[10]  fixed 

ft 

FUeType 

uchar 

[11]  fixed 

ct 

Compression  Type 

uchar 

[12..  13]  fixed 

bo 

Body  Offset 

uint 

[14]  fixed 

dc 

Download  Count 

uchar 

[15..20]  fixed 

sc 

Source 

aiTay[6]  of  uchar 

[21]  fixed 

pr 

Priority 

uchar 

[22..25]  fixed 

ut 

Upload  Time 

ulong 

[26.  .29]  fixed 

et 

Expire  Time 

ulong 

[30.. 37]  fixed 

m 

PANSAT  File  Name 

arniy[8]  of  uchar 

[38.. 40]  fixed 

ex 

PANSAT  File  Extension 

aiTay[3]  of  uchar 

[41]  fixed 

nd 

Number  of  Destinations 

uchar 

[42.. 47]  approx. 

ds 

Destination  1 

array[6]  of  uchar 

[48.. 53]  approx. 

Destination  2 

aiTay[6]  of  uchar 

[54.  .59]  dpprox. 

Destination  3 

array[6]  of  uchar 

[60.. 65]  fjprox. 

Destination  4 

array[6]  of  uchar 

[66.. 71]  approx. 

Destination  5 

array[6]  of  uchar 
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TABLE  3.1  PANSAT  FILE  HEADER  FIELDS  | 


Byte(s) 

Const 

Name 

Format 

r72..77]  aiq>rDx. 

Destination  6 

aiTay[6]  of  uchar 

[78-83]  ^^rox. 

Destination  7 

arniy[6]  of  uchar 

Title  Loigth 

uchar 

ti 

Tide 

arraypO]  of  uchar 

[115]  i^rox. 

Keyword  Length 

uchar 

[116..  195]  approx. 

kw 

Keywords 

aiTay[80]  of  uchar 

[196..  197]  approx. 

Header  Checksum 

uint 

[198..  199]  approx. 

Body  Checksum 

uint 

C.  FIELDS  TO  BE  FILLED  IN  BY  SOURCE 

A  PANSAT  file  header  must  be  prepended  to  any  file  before  it  is  uploaded  to  the 
satellite.  Certain  fields  within  the  header  must  be  completed  by  the  user  station  where 
the  file  originates,  while  other  fields  are  filled  in  by  the  satellite  once  the  file  has  been 
completely  uploaded.  The  user  must  place  all  zeros  in  those  fields  which  the  satellite 
will  complete.  These  satellite  responsible  fields  will  all  be  of  fixed  length.  The  fields 
for  which  the  user  is  responsible  are  as  follows: 

1.  Flag 

The  flag  indicates  that  this  is  the  beginning  of  a  file  with  a  PANSAT  file 
header.  The  flag  must  always  consist  of  the  same  two  bytes:  ’OxBB’  followed  by  ’OxSS’. 
Example  of  the  flag  field:  10111011  01010101. 
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2.  A&dl  Number 

A  mail  number,  or  file  number,  is  assigned  by  PANSAT  to  each  file.  This 
number  is  not  known  to  the  user  until  it  is  provided  by  the  satellite  in  an  upload_go_resp 
following  an  uploadjmd  from  the  ground  station.  (See  Chapter  VI,  secticm  E.).  The 
user  software  has  two  options  here.  The  simplest  is  to  leave  4  bytes  of  O’s  in  this  field, 
and  1^  the  satellite  update  it  after  the  upload.  If  the  upload  is  interrupted,  however,  it 
will  be  the  responsibility  of  the  user  software  to  "remember”  the  number  associated  with 
the  partially  uploaded  file,  and  to  provide  it  to  the  satellite  in  the  next  upload_and  which 
will  continue  the  process.  The  obvious  place  to  store  the  number  is  in  the  file  header. 
For  this  reason,  it  may  make  more  sense  to  choose  the  second  option,  which  is  to  place 
the  proper  number  in  the  header  before  transmission  of  the  file  begins.  Of  course,  this 
will  also  necessitate  adjusting  the  header  checksum  before  transmitting.  (See  subsection 
12). 

3.  File  Length 

The  file  length  is  a  four  byte  unsigned  integer  (ulong).  The  source  software 
must  place  in  this  field  the  number  of  bytes  contained  in  the  file,  including  the  PANSAT 
file  header. 


12 


4.  File  Type 


The  file  type  is  a  one  byte  field  which  indicates  the  fonnat  of  the  file  body. 
The  satellite  does  not  care  about  the  file  fotmalt  as  it  treats  all  files  simply  as  arrays  of 
bytes.  The  information  in  this  field  is  fm^  the  use  of  anyone  who  downloads  the  file,  so 
that  diey  will  know  how  it  must  be  read.  The  contents  of  this  field  will  be  interpreted  as 
in  Table  3.2.  The  first  elevoi  of  these  types  are  the  same  as  those  defined  by  Price  and 
Ward  in  [Ref.  7],  and  some  of  them  might  never  be  used  aboard  PANSAT.  They  are 
included  for  completeness,  and  to  provide  as  much  parallelism  as  possible  between  this 
specification  and  FTLO. 


1  TABLE  3  J  FILE  TYPES  | 

Field  Contents 

File  Type  | 

ASCn  file  1 

00000001 

RLI/MBL  message  body.  Single  message.  | 

00000010 

RLI/MBL  import/export  file.  Multiple  message.  | 

00000011 

UoSAT  Whole  Orbit  Data  1 

00000100 

Microsat  Whole  Orbit  Data  ] 

00000101 

UoSAT  CPE  Data  I 

00000110 

MS/PC-DOS  .exe  file 

00000111 

MS/PC-DOS  .com  file 

00001000 

Keplerian  elements  NASA  2-line  format 

00001001 

Keplerian  elements  "AMSAT”  format 

00001010 

Simple  ASCn  text  file,  but  compressed 
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TABLE  3  J  FILE  TYPES 


Pldd  Contoits  I  FUel^pe 


lOlOOOOO 

10100001 

10100010 

11111110 


PANSAT  short  format  tdeinetry  file 
PANSAT  long  format  telemetry  file 

PANSAT  bax  tdemetry  file _ 

User  defined  Qrpe. 


5.  ComiMession  Type 

If  the  body  of  the  file  is  compressed,  the  source  must  indicate  the  type  of 
compression  used  in  this  one  byte  field.  Again,  the  satellite  does  not  care  whether  or  not 
a  file  is  compressed,  or  if  so,  how.  This  information  is  for  the  use  of  the  downloading 
user  only.  Note  that  no  matter  what  file  format  or  compression  type  is  used  in  the  file 
body,  the  PANSAT  file  header  will  alwc  s  be  uncompressed  ASCII  text.  Compressitm 
types  are  indicated  by  Table  3.3.  ”Usie^  defined  type”  in  Table  3.2  and  "Other”  in 
Table  3.3  indicate  that  a  file  format  or  compression  type  not  listed  is  being  used.  The 
user  must  know  the  type,  perhaps  based  (hi  the  source  or  title. 


TABLE  3.3  COMPRESSION  TYPES 
Field  Contents  I  Compression  Type 


00000001 

00000010 


No  compression 

PKARC 

PKZIP 


00000011 


Other 
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€,  Body  CMTset 

The  body  offset  is  a  two  byte  unsigned  int^o^  (uint).  The  source  must  ento' 
in  diis  field  the  byte  number  at  which  the  file  body  begins;  that  is,  the  number  of  the 
byte  following  die  last  byte  in  the  PANSAT  file  headm^.  This  is  where  dw  file  fmmat 
and  C(Hiqpression  type  will  take  effect,  as  for  as  the  ground  user  is  concerned.  Note  diat 
the  first  byte  in  die  file  header  is  number  0.  If  there  are  200  bytes  in  the  file  header, 
then  die  body  offset  will  be  *200’  (OxOOCS). 

7.  Source 

The  source  fidd  identifies  the  origin  of  the  file,  or  the  ground  station  from 
which  it  was  uploaded.  The  uploading  user’s  HAM  callsign,  consisting  of  six  ASCII 
characters,  must  be  altered  in  this  fidd  by  the  client  software. 

8.  Priority 

No  particular  use  for  the  one  byte  priority  fidd  is  currently  specified  for  the 
satellite  software.  The  user  is  free  to  use  this  fidd  for  his  own  purposes,  such  as  to 
indicate  the  rdative  urgency  of  messages  to  addressees  who  share  the  same  interpretation 
for  this  fidd.  Any  one  byte  bit  pattern  may  be  ottered  in  the  fidd,  as  long  as  the  header 
checksum  takes  the  contents  into  account. 

9.  Number  of  Destinations  and  Destination  1  through  Destination  7 

If  the  message  to  be  uploaded  is  intended  for  receipt  by  between  1  and  7 
individual  destination  stations,  then  this  is  the  number  which  is  placed  in  the  (me  byte 
unsigned  integer  of  the  "Number  of  Destinations"  fidd.  The  appropriate  number  of 
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Deliiiiiiwi*  fiektoaietiicnyiedtoiadtcalelfaeHAMcallrigiisofthcaddicsiBet.  Any 
mused  destinatioa  fidds  are  Idt  out  of  the  header.  If  the  source  wishes  to  indicale  that 
a  message  is  intended  for  all  usen,  then  die  number  *0x00’  is  {daoed  in  the  "Number  of 
Destinations"  field,  and  no  destination  fidds  are  used. 

To  modify  the  "all  users"  desdnation,  die  iqiloading  station  may  choose  to 
indude  a  "source  path"  or  a  "destination  path"  to  further  define  the  intended  audienoe 
for  the  file.  If  a  source  path  is  to  be  included,  then  the  number  *0x08’  is  placed  in  the 
"Number  of  Destinatimis"  fidd,  and  all  7  of  the  destination  fidds  are  induded  as  a  single 
42-byte  path  fidd.  Any  ASCII  string  may  be  placed  in  this  field  to  indicate  a  source 
path  or  other  source  identification.  Similarly,  if  a  destination  path  is  to  be  induded,  die 
number  *0x09*  is  placed  in  the  "Number  of  Destinatimis”  field,  and  the  42-byte  path  fidd 
is  used  to  indicate  a  destination  path  or  to  identify  the  intended  audience. 

The  satellite  will  not  attempt  to  interpret  destinatitm  paths  or  identifications. 
It  is  up  to  the  potential  downloaders  to  use  this  informatimi,  either  by  reading  it  after 
downloading  file  directories,  or  by  providing  strings  to  compare  with  the  path  fidd  in 
seieajmds  (see  Chs^iter  VI). 

10.  Title  Length  and  Title 

The  "Utle"  field  is  a  variable  length  array  of  from  0  to  30  bytes.  The  "Title 
Length’'  field  must  be  entoed  by  the  source  to  indicate  the  actual  length  of  die  tide.  The 
tide  should  be  an  ASCII  string  which  will  indicate  to  potential  downloaders  the  contents 
of  the  file  body.  If  time  is  an  original  file  name,  which  it  is  important  to  keqi  with  the 
file,  it  may  be  entered  here.  PANSAT  does  not  otherwise  retain  original  file  names. 
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awltiiit^  its  own  tfker  i^loid.  The  title  information  is  for  the  use  of  potential 
dosrakMiden  only,  and  die  aatdHte  does  not  attenqit  to  intopret  this  field. 

11.  Keyword  l^eagth  and  Keywords 

Like  the  *Tide*  field,  die  "Keywords”  fidd  is  a  variable  length  array  of 
ASCn  charaders.  The  "K^word  Length*  field  must  be  used  to  qwdfy  die  actual 
lengdi,  of  between  0  and  80  bytes.  Keywmds  should  be  sqiarated  from  eadi  other  by 
one  or  more  qnoes.  The  satellite  does  intet|»iet  keyword  information,  but  will  attmnpt 
to  find  keywords  of  interest  within  this  field  if  so  directed  by  a  selectjcmd. 

12.  Header  Checksum  and  Body  Checksum 

The  header  and  body  checksums  are  used  to  verify  the  int^rity  of  a  file  after 
u|doading  or  downloading  is  complete.  The  body  checksum  must  be  calculated  first, 
since  it  is  included  in  the  header  and  is  thus  a  foctor  in  the  heada  checksum.  All  bytes 
in  die  body  of  the  file  are  added  together  as  unsigned  8>bit  integers.  The  least  significant 
two  bjrtes  of  die  resulting  sum  are  placed  in  die  body  checksum  field.  The  header 
diecksum  is  the  result  of  adding  all  bytes  in  the  header  together,  excqit  for  the  header 
dwcksum  itsdf,  and  taking  the  least  significant  two  bytes  of  the  sum.  The  source  must 
take  care  to  update  the  diecksums  if  any  part  of  the  file  or  heado-  is  changed  before  the 
actual  iqdoad  b^ins.  When  the  file  number  to  be  used  has  been  idoitified  by  the 
satellite,  for  instance,  if  the  scHirce  thoi  rqilaces  the  zeroes  in  the  "File  Number”  field 
with  the  propo’  number,  those  four  bytes  must  also  be  added  to  the  header  checksum. 
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If  tile  aoufce  is  not  aUe  or  does  not  desire  to  olculate  diese  checksums, 
either  or  bodi  (rf  dumi  may  be  left  out.  In  this  case,  the  fidds  must  be  ftUed  with  all 
aeroes.  The  satdlite  will  not  fill  in  or  update  "all  zero"  checksum  fields.  When  the 
aiellite  performs  file  integrity  checks,  any  all  zero  checksum  will  be  ignored  and  that 
check  will  be  skipped.  Because  of  this,  corrupted  files  may  remain  aboard  the  satellite 
undetected.  It  is  iqi  to  the  file’s  source  to  determine  whether  checksums  are  required. 
Currently,  diere  is  no  way  to  distinquish  bdween  "no  checksum"  and  a  checksum  which 
is  actually  *0’.  Consequently,  any  checksum  which  is  calculated  to  be  exactly  zero  will 
be  ignored.  This  can  be  remedied  by  adding  a  character  to  the  Keywords  or  Title  field, 
acQusting  the  qipropriate  length  field  and  recalculating  the  checksum. 

D.  FIEIJ^  TO  BE  FILLED  IN  BY  SATELLITE 

As  [meviously  stated,  the  uploading  source  of  a  file  may  choose  to  leave  the  "File 
Number"  field  of  the  PANSAT  file  header  filled  with  zeroes.  If  the  satellite  finds  that 
this  has  been  done,  it  will  fill  in  this  field  and  update  the  header  checksum  appropriately. 
When  the  satellite  "updates"  a  checksum,  it  does  so  simply  by  adding  to  it  any  bytes  with 
whidi  it  has  rq;>laced  zeroes.  When  mmzero  field  contents  must  be  changed,  the  existing 
bytes  are  subtracted  from  the  checksum,  and  the  new  bytes  added  to  it.  This  happens, 
for  instance,  when  the  "Download  Count"  is  updated  (see  below).  The  least  significant 
two  bytes  of  the  sum  are  placed  into  die  diecksum  field.  The  checksum  is  not 
comfdetdy  recalculated,  as  this  would  invalidate  the  purpose  of  checking  the  integrity  of 
die  bytes  ufdoaded. 
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Theie  are  revenl  additional  fields  widiin  the  PANSAT  file  header  which  must  be 
filled  in  by  die  satellite.  The  satellite  software  iqKlates  the  header  checksum  whenevo* 
it  piaoes  infimaialion  in  any  of  diese  fields.  The  satdlite  will  never  change  a  body 
checksum.  The  satellite  re^onsible  fields  are  described  in  die  following  subsections. 

1.  Download  Count 

In  diis  one  byte  field,  the  satellite  software  keqis  track  of  how  many  times 
a  particular  file  has  been  successfully  downloaded.  For  a  file  addressed  to  ”all”,  the 
download  count  is  incremented  each  time  a  download  is  completed.  For  a  file  addressed 
to  between  one  and  seven  individual  callsigns,  the  count  is  incremented  only  when  a 
download  is  comid^ed  to  one  of  the  intended  addressees.  The  infbrmatiiMi  in  this  field 
is  used  to  detennine  whether  a  file  has  been  i»eviously  downloaded  when  the  default 
selection  list  is  being  formed  (see  Cluyner  VI,  section  K).  The  satellite  software  looks 
at  die  header  of  eadi  file  to  see  if  the  currait  client  is  one  of  the  addressees.  If  there  are 
five  addressees  listed,  for  instance,  and  the  client  is  one  of  them,  but  the  download  count 
is  already  at  *5’,  it  is  assumed  that  the  client  has  already  downloaded  this  file. 

2.  U|rioad  Time  and  Exirire  Thne 

The  "Upload  Time"  field  is  filled  in  after  a  complete  file  has  beat 
successfully  uploaded.  When  the  final  bytes  of  a  file  have  been  received,  and  the  file 
has  passed  the  int^rity  diecks  (such  as  checksums),  the  satdlite  "stamps"  it  with  its 
current  onboard  time.  This  time  is  in  the  form  of  a  four  byte  unsigned  int^er  which  is 
a  count  of  die  number  of  seconds  since  January  1,  1970  (the  UTC,  or  Universal  Time 
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CBmUhQ,  Then  ttie  cinmtt  amount  of  tiine  allotted  to  eadi  fite  to  stay  tboud  die 
mdlhe  is  added  to  die  iqrioad  time  to  fimn  die  expiration  time.  This  number  is  idaoed 
in  the  EiqMie  TUne  fidd.  The  amount  of  time  allowed  for  each  file  may  change  based 
upon  satdlite  loading.  When  the  cqMntion  dme  for  a  file  is  exceeded  by  die  clock 
onboard  die  saldlite,  that  file  is  discarded. 

3.  PANSAT  FDe  Name  and  PANSAT  File  Extension 

As  each  file  is  uidoaded  to  the  satellite,  the  satellite  software  assigns  a  DOS 
file  name  and  extension  to  it.  This  is  the  file  name  which  will  be  used  by  the  onboard 
file  management  system  to  access  the  file.  It  is  also  used  to  easily  associate  each  file 
widi  it*s  source  without  having  to  read  any  header  fidds.  The  8-byte  file  name  assigned 
oondsts  of  the  6  character  source  callsign  preceded  by  two  ASCII  spaces.  The  file 
extension  condsts  of  3  ASCII  numerals  (0  through  9),  which  indicate  the  sequence  of 
files  ufdoaded  from  this  particular  source.  For  instance,  the  first  file  uploaded  by 
callsign  ABCDEF  would  be  named  ”  ABCDEF.OOl”,  the  secrnid  would  be 
”  ABCDEF.002",  etc.  Extensions  are  iqieated  after  number  ”999".  It  is  unlikdy  that 
any  file  would  remain  with  an  extension  that  is  up  for  re-use.  But  if  that  happens,  the 
next  unused  extensitm  will  be  assigned  instead. 

Certain  file  names  are  used  by  die  satellite  to  indicate  particular  kinds  of  files 
generated  idioard  the  satdlite,  rather  than  uploaded  by  users.  These  include 
"BULLEi  lN.xxx"  and  "USRTELEM.xxx”.  Files  with  the  name  "BULLETIN"  contain 
information  of  general  interest  posted  by  the  satdlite  or  ground  ccmtrol  qierators  and 
addressed  to  ail  users.  Files  with  the  name  "USRTELEM"  contain  satellite  telemetry 
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iHMcIi  n^f  te  of  iittefeit  to  uaen.  USRTELEM  files  will  be  in  die  format  *PANSAT 
dioft  telemetry  file*,  lliis  format  has  not  been  com]deldy  qiedfied  as  yet,  and  will  be 
published  tt  a  li^  date. 
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IV.  THE  SFECinCATK)»^  LANGUAGE  >  ESTELLE 


A.  FORMAL  DESCRIPTION  TECHNIQUE 

A  formal  description  teduiique  (FDT)  is  a  method  of  precisely  defining  the 
bdiavkv  of  a  ^stmn.  It  is  generally  advantageous  to  employ  an  FDT  in  the  detign  and 
spedfication  of  software  because  descriptions  produced  in  this  way  tend  to  be  more 
omnpiele,  consistent,  precise,  concise,  and  unambiguous  than  descriptions  produced  in 
a  natural  language,  such  as  English.  F<n’  the  q)eciftcation  of  the  PANSAT  flight 
software,  the  language  Estdle  has  been  dK)sen.  Estelle  is  a  formal  description  technique 
w^ch  is  based  on  an  extended  state  transiticm  model  and  uses  much  of  the  familiar 
syntax  of  die  i»Dgramming  language  Pascal.[Ref.  8] 

As  staled  in  ChsqMer  n,  the  operating  system  chosen  for  the  computer  aboard 
PANSAT  supports  software  written  in  the  "C"  programming  language.  For  this  as  well 
as  otiier  reasmis,  such  as  development  and  dd)ugging  tools  currently  available  to  the 
Space  Systems  Academic  Group  at  NFS,  the  implementation  languages  for  the  flight 
software  will  be  *C",  "€++”,  and  assembly  code  as  required.  In  ^te  of  this,  there 
are  many  reasons  ftn*  develofting  the  software  ^lecification  in  a  descripticm  language  lilm 
Estelle,  prim  to  inq>lementing  it  in  a  compilable  language  such  as  "C".  Some  of  these 
reasons  are  addressed  in  the  fdlowing  secticms. 


B.  CLARITY 

One  of  the  most  impoitent  aspects  of  a  software  qiecification  is  clarity.  The 
purpose  of  tfie  spedScalkm  is  to  clearly  communicate  die  intended  behavior  of  the 
prosrim  to  dxMe  vdio  must  actually  write  the  software  (both  the  original  version  and 
later  revisions)  as  well  as  to  those  who  must  use  it.  The  behavior  described  by  the 
qiedfication  must  be  verifiable  to  be  the  correct  behavior  by  the  systems  designers  who 
define  the  requirements  of  the  system.  A  inogramming  language  like  "C  is  certainly 
very  precise,  but  is  often  lacking  in  the  required  clarity,  at  least  as  far  as  humans  other 
dian  the  original  programmer  are  concerned. 

A  particular  ”C*  statement  is  written  in  a  particular  way  and  will  cause  a  particular 
event  to  occur.  What  is  not  obvious  is  whether  the  particular  ev«it  that  occurs  is  exactly 
the  event  intended.  When  some  software  requiremoit  is  translated  directly  from  an 
English  description  into  a  programming  language  implementation,  there  are  several 
dangers.  First  of  all,  it  is  difficult  to  guarantee  that  the  English  description  is  sufficiently 
unambiguous  that  it  will  be  understood  and  translated  in  exactly  the  same  way  by 
everyoiw.  Sectxid,  if  the  translation  is  off  somewhat  and  the  software  written  implemoits 
a  slightly  differait  requirement  than  that  intoided,  it  can  be  difficult  to  catch  the  error 
by  examining  the  code.  Third,  since  the  code  is  more  precise  than  the  original  English 
description,  it  may  be  tempting  to  use  it  as  the  description  of  required  bdiavior  as  the 
jnogram  is  dd)ugged  and  modified.  Some  programming  languages,  ”C"  in  particular, 
are  sufficirady  terse  that  it  can  be  difficult  to  extract  a  complete  understanding  of  the 
intmided  behavior  directly  from  the  code  without  intense  examination.  Commoits  are 


23 


«mI  to  tSMatit  tfris  pvoblem  >  and  we  ««  bade  to  die  andHguities  oi  die  En^ish 
In^uaie.  Of  ooiine,  even  if  a  predaedeacr^idon  of  betavkir  is  extracted  from  die  code 
and  oomments,  it  may  no  longer  be  die  intended  one. 

Hie  Pascal  syntax  used  in  E^dle,  diough  more  precise  and  unamtnguous  than 
English,  is  more  obvkws  and  easily  readable  than  *0”.  Simple,  well-understood,  and 
extremely  precise  programming  language  constructs  are  used.  These  include  whik 
statmnoits,  if-then-dse  constructs,  and  for  loops,  as  well  as  ftmedem  and  procedure  calls 
[Ref.  8].  The  qiecific  Pascal  syntax  used  in  Ajqiendix  A  is  summarized  in  Appendix  C, 
Table  C.  1.  Pascal  was  developed  as  an  educational  language  and  is  designed  ^lecifically 
to  be  clear  and  easily  understood;  the  syntax  is  very  straight  forward.  The  intricate  and 
often  inscrutable  statement  omstruction  of  a  high-powered  language  such  as  *€"  is 
avoided. 

Using  Estelle,  an  English  description  of  required  behavior  can  be  translated  into 
a  precise  series  of  program-like  statements.  These  statements  are  sufficiently  readable 
that  the  resulting  behavior  can  be  easily  analyzed  and  compared  with  the  intended 
requiremoits.  An  ambiguous  requirement  statement  is  made  crystal  clear,  once  it  has 
been  set  down  in  the  proper  series  of  precise  Estelle  statements.  Once  the  formal 
specification  is  in  place,  thme  should  be  <mly  one  way  to  translate  it,  the  correct  way. 
Any  software  implementation  must  then  be  checked  against  the  required  behavior 
imparted  by  the  Estelle  desoiption.  Whoi  the  program  does  not  act  in  a  useful  way,  it 
can  be  easily  determined  whether  the  original  requirements  statement  was  at  fault,  or 
whether  the  {nogram  code  is  flawed.  When  the  software  must  be  modified  throughout 
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tile  life  cycle  of  the  host  system,  the  originally  intended  behavior  of  the  existing  code  will 
be  moxt  easily  understood  from  the  qiecificatitti  than  from  the  code  itself. 

Of  course,  the  qiecification  must  be  nuuntained  up-UMlate  along  with  the  code. 
If  the  system  lequiranents  change,  this  must  be  reflected  in  the  qiedrication.  The 
^ledficatimi  should  always  be  the  most  accurate  description  of  the  currmitiy  intended 
bdiavkv  of  the  software  system. 

C.  STATE  MACHINE  MODEL 

Many  software  systems,  including  communications  protocols,  can  be  modeled  as 
state  machines.  A  major  function  of  the  PANSAT  flight  software  is  to  implement 
communicaticMis  and  file  transfer  protocols  betwemi  the  ground  users  and  the  satellite. 
State  machines  provide  a  convenicmt  way  of  modeling  the  software  and  describing  its 
required  behavior.  Estelle  extends  the  syntax  of  Pascal  to  include  constructs  specifically 
designed  to  clearly  convey  a  state  machine  architecture.  The  behavior  of  each  module 
is  defined  by  its  reactions  to  each  legal  stimulus  it  may  receive  while  in  each  specific 
state.  Even  where  several  different  states  are  not  required  for  the  proper  functioning  of 
a  module,  the  state  machine  architecture  still  provides  a  convenient  way  to  show  the 
module’s  reactions  to  different  inputs,  and  provides  a  means  of  identifying  what  inputs 
are  anticipated  and  legal  and  what  inputs  are  illegal  or  unexpected. 

While  individual  statements  primarily  use  common  Pascal  syntax,  the  hierarchy  of 
the  program  modules  and  the  module  interface  are  defined  by  the  Estelle  state  machine 
modd.  There  are  Estelle-specific  reserved  words  which  are  used  to  establish  the  state 
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inidiiiie  ar^UBCture  and  to  define  other  aqwcts  of  the  specification  i^diidi  are  beyond 
die  scope  of  the  Pascal  syntax.  These  reserved  words,  the  specification  s^moits  with 
which  they  are  associated,  and  their  functicms  are  listed  in  Appendix  C,  Table  C.2. 

D.  MODULE  COMMUNICATIONS 

Communications  between  various  program  modules  are  very  clearly  defined  in 
Estelle.  What  types  of  information  are  passed  between  precisely  which  prc^ram  modules 
is  dioroughly  qielled  out.  The  set  of  channel  definitions,  which  controls  the  fiow  of 
information  between  modules,  is  also  the  module  interface  definition. 

In  the  software  specification,  several  channels  are  defined.  Each  channel  definition 
includes  a  list  of  the  message  types  which  can  be  "passed”  through  that  channel.  Each 
end  ot  the  channel  is  named  and  the  message  types  are  direction-specific.  For  instance, 
module  *A*,  attached  to  the  ’User*  end  of  a  particular  channel,  may  request  information 
fiom  module  ’B’,  at  the  ’Provider’  end,  using  one  of  several  different  ’request’ 
messages.  Module  ’B’  will  rq>iy  using  one  of  a  completely  different  set  of  ’response’ 
messages. 

The  name  of  a  message  type  and  the  channel  it  is  passed  through  may  in  itself 
provide  all  the  information  that  is  needed.  In  other  situations,  qiecific  parameters  must 
be  passed.  The  parameters  to  be  passed  with  each  message  are  listed  in  parenthesis  next 
to  the  message  name  in  the  channel  definition.  Estelle  is  a  strongly  typed  language,  and 
this  requiremoit  extrads  to  the  parameters  passed  between  modules.  The  type  of  each 
parametm’  is  indicated  in  the  message  definition. 
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Each  program  module  has  a  module  header  definition  and  a  module  body 
definition.  The  module  header  definition  includes  a  list  of  all  the  "interaction  points" 
available  to  the  module.  These  interaction  points  are  duumels,  and  die  end  of  the 
channel  to  which  the  module  is  attached  is  imlicated  for  each.  The  intoaction  p(^ts  ate 
the  only  means  by  whidi  information  can  be  passed  from  one  module  to  anotho-.  The 
nature  of  each  information  exchange  is  thus  |»ecisely  defined.  In  tlw  modvar  section 
at  the  end  of  the  software  ^lecificatitm,  channels  are  attached  explicitly  betwera  the 
various  modules.  The  channel  definitions,  module  header  definitions,  and  the  modvar 
section,  taken  together,  completely  define  the  architecture  of  the  software  system. 

£.  DETAIL  AND  ABSTRACTION 

One  final  advantage  of  using  a  formal  description  technique  such  as  Estelle,  is  that 
various  levels  of  abstraction  can  be  used  to  clarify  the  ^>ecification.  Abstraction  can  be 
used  to  ignore  details  irrelevant  to  the  context  at  any  point,  so  that  the  local  complexity 
of  the  description  can  be  decreased  and  the  overall  understanding  increased.  Abstraction 
can  also  be  used  to  continue  with  a  descripticm  even  though  some  essential  details  are  not 
yet  known.  Commonly  used  functions,  such  as  those  assumed  to  be  readily  available 
from  the  rqierating  system,  can  be  defined  as  "primitives",  the  actual  details  of  their 
intonal  implemoitations  unimportant.  Hardware  qiecific  details  which  are  not  known 
when  the  qiedfication  is  being  developed  can  be  defined  abstractly,  with  the  specifics 
to  be  filled  in  later. 
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b  ooMnst,  any  levd  of  detail  desired  can  be  induded.  Thus,  if  minute  details  of 
die  ^wcific  hardware  inqdmnentatimi  tobe  used  are  known,  diey  can  be  indicated  in  the 
specification  to  avoid  mistakes.  Detailed  algorithms  which  demonstrate  a  method  for 
obtaining  the  qiedfic  results  desired  can  be  drawn  out.  In  the  qiedfication  of  Appendix 
A,  the  communications  jmitocols  and  mailbox  control  are  described  in  somewhat  minute 
detail,  at  a  level  where  ^wcific  hardware  requirements  are  unimportant.  The  portions 
of  the  specification  dqmidant  upon  hardware  configurations  are  merely  indicated  in  a 
high-level  architecture,  with  all  details  to  be  worked  out  as  more  information  becomes 
available. 
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V.  DATA  TRANSFER  MODULE 


A.  FUNCnON 

The  DATA  ^TRANSFER  module  provides  die  interfisce  between  die  high  level  file 
tnmsftr  pioioad  used  by  PANSAT  and  the  BAX  link-level  AX.25  i»otocol  software. 
It  is  die  primary  "BAX  i^licadon  program."  The  PACKETJTRANSFER  module, 
described  in  Chapters  VI  and  vn,  relies  on  the  data  transfer  module  to  reassemble  the 
AX.25  level  frames  passed  ftom  BAX  into  the  comply  packets  uplinked  from  the 
ground  station.  The  data  transfer  module  also  receives  packets  from  the  packet  transfer 
module,  breaks  them  down  into  frames,  ami  passes  diem  on  to  BAX  to  be  transmitted 
to  the  intended  user. 

B.  THE  BAX  CONTROL  BLOCK 

Communication  with  the  BAX  program  is  accomplished  via  the  BAX  functions 
liried  in  Chayiter  n.  These  are  rqnesented  in  the  Estelle  specification  of  Aj^ioidix  A  by 
the  message  types  widun  the  Abstract_Bax_Channel.  Many  of  these  messages  have  a 
parameter  of  the  type  Ccmtrol^Block.  The  control  block  is  a  data  structure  detined  in 
[Ref.  4]  which  carries  mudi  of  the  actual  information  passed  between  BAX  and  the 
t^lication  program.  QAX_CLEAN_CB  is  a  BAX  function  which  provides  a  cmitrol 
bkick  structure  with  all  Adds  initialized  to  rero.  This  is  the  cmly  BAX  functitm 
rderenced  in  die  qiecificaticHi  by  a  procedure  call  rather  than  by  a  message  type. 
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Tbe  definitioii  of  the  Cootrol.Block  type  Mppem  aomev^  diffoentiy  in 


Appendix  A  dian  in  [Ref.  4].  It  has  been  altoed  to  matdi  the  syntax  and  avoid  the 
reserved  words  of  die  remainder  of  the  specification  and  includes  only  those  fidds  which 
are  actually  used  by  die  data  transfer  module.  The  control  block  fields  used  are  listed 


in  Table  S.l  altmg  with  the  infbrmati<m  each  conveys. 


1  TABLE  5.1  BAX  CONTROL  BLOCK  FIELDS  | 

Af^.  A 
Name 

(Ref.  4] 

Name 

Type 

Information 

link 

channel 

uint 

Indicates  which  of  the  30 
possible  BAX  links  a  frame 
has  come  in  on,  or  which  it 
should  be  sent  out  over.  In 
effect,  designates  the  ground 
user  at  the  other  «id. 

kind 

type 

numerated 

FrameJType 

Indicates  the  type  of 
information  carried  by  the 
control  block.  If  qatjiata, 
thoi  the  data  from  a  data 
frame  has  been  placed  in  an 

Fdata  buffer,  included  as 
another  message  parameter.  If 
qatjtate,  then  the  state  of  the 
link  has  changed,  and  the  new 
state  is  indicated  by  the 

T_state’  field.  If  qatju,  then 
an  unnumbered  information 
frame  has  been  received. 
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1  TABLE  5.1  BAX  CONTROL  BLOCK  FIELDS  | 

App.  A 
Nune 

[Ref.  41 

Name 

Type 

InfonnatkMi 

l_state 

state 

enumerated 

Link_State 

Indicates  the  new  link  state  in 
a  qat_5tate  kind  of 
Control^Block.  Only  two  of 
these  states  concern  the  data 
transfer  module: 
qasjMimect _pend  indicates 
that  a  user  has  requested  to  be 
cmmected  with  the  satellite. 
qas^disconnected  indicates  that 
a  user  link  has  beoi 
terminated..  The  reason  for 
termination  can  be  determined 
from  the  ’why’  field. 

why 

cause 

enumerated 

Cause 

Indicates  the  reas(Mi  for  a  link 
state  change.  Causes  include 
qacjocal  (action  of  the 
satellite),  qacjremote  (action 
of  the  ground  station), 
qacjremotefirmr  (AX.25 
protocol  error)  and 
qaejimeout  (maximum 
number  of  frame  retries 
exceeded). 

my_call 

struct 

AX25_ADDR 

my_call 

CallsignJType  =* 
array[6]  of  uchar 

Indicates  the  {q>plication 
program’s  call  sign,  which  is 
always  the  satellite’s  call  sign. 

my_ssid 

uchar 

Indicates  the  application’s 
subsystem  identification 
numbmr  (to  distinguish  the  data 
transfer  module  from  the 
ground  control  module,  for 
instance).  | 
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TAMJ3.1  BAX  C0Wn01.11X)CK  FIELDS _ I 

App.  A 
Name 

[iur.4] 

Name 

Type 

iBfonnatkm 

his_call 

struct 

AX25_ADDR 

his^caii 

Callsign_Type 

Indicates  the  ground  station’s 
call  sign. 

his_ssid 

uchar 

Indicates  the  ground  station’s 
subsystem  identification 
number 

tl 

tl 

uchar 

The  number  of  seconds  to  use 
for  the  link-level  frame 
timeout-timer.  If  a  frame 
acknowledgement  is  not 
received  within  tl  seconds  of 
transmission,  the  frame  must 
be  retransmitted. 

maxhrame 

maxframe 

uchar 

The  maximum  number  of 
frames  "in  flight"  at  one  time  - 
the  link-level  sliding  window 
size.  Must  be  1  -  7. 

retry 

retry 

uchar 

The  maximum  number  of 
times  to  retry  a  frame 
transmissicm  before  terminating 
the  link. 

paclen 

paclen 

uint 

The  maximum  size  of  the  data 
field  on  an  outgoing  frame. 

Must  be  <  =  256  bytes. 

C.  STATES  OF  THE  DATA  TRANSFER  MODULE 

The  data  transfer  module  has  only  two  states,  NORMAL  and  BUSY.  The  module 
is  initialized  in  the  NORMAL  state,  and  is  expected  to  remain  in  that  state  for  the 
nugority  of  the  time.  A  transition  to  the  BUSY  state  occurs  only  as  the  result  of  a 
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— horn  die  eidm’  die  OROUND_C(^'nitOL  module  or  the  AUTO_CONTROL 
module. 

If  die  performance  of  the  satellite,  as  judged  by  die  onboard  ded^-making 
software  or  by  die  ground  oontrd  station,  deteriorates  to  the  point  where  it  seems 
to  allow  fewer  users  to  access  the  satdlite  for  a  pmod  of  time,  a  lockout 
message  can  be  sent  to  the  data  transfer  module.  The  type  of  lockout,  (T^ldnd’)  may  be 
new-user  or  a//-user.  When  a  new-user  lockout  message  is  received,  the  data  transfix 
module  remains  in  the  NORMAL  state,  but  rejects  all  new  user  connection  requests.  The 
satellite  will  continue  communications  with  all  users  already  logged  on  when  the  message 
is  received.  When  the  data  transfer  module  receives  an  a//-user  lockout  message,  the 
state  will  change  to  BUSY  and  incoming  communications  from  evoyone  excqit  the  NFS 
ground  cmitrol  staticm  will  be  rejected.  The  data  transfer  module  will  send  a  ’busy’ 
message  to  every  BAX  link,  and  BAX  will  reqxMid  to  any  frame  (except  those  from 
NFS)  with  a  ”receive-not-ready"  frame. 

The  control  software  may  also  find  it  necessary  to  turn  the  transmitto’  off  for  an 
extended  period  of  time,  such  as  during  a  batt^  recharge.  When  this  occurs,  and  the 
transmittm’  will  not  be  ready  at  a  moment’s  notice,  a  'transmittm’.ofT  message  will  be 
sent  to  die  data  transfer  module.  This  message  will  not  change  the  state  of  the  module, 
whidi  will  still  be  able  to  receive  any  incoming  frames,  but  it  will  change  the  srate 
variable  ’transmit_ok’  to  false.  When  this  occurs,  the  data  transfer  module  will  not 
attempt  to  transmit  any  frames,  and  any  logged-in  users  will  most  likely  disconnect  due 
to  frame  time-outs. 
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VL  PACKET  nUNSFER  MODULE  -  PACKET  TYPfS 


A.  FILE  TKANSIEK  LEVEL  0 

The  pedket  tnnsfer  raoihile  specified  in  ^ipendix  A  has  its  origins  in  the  File 
TaoMiu  Levd  0  (FTLO)  PKsat  Protoad  dev^)ped  by  Ward  and  Harold  E.  Price 
ptef.  7].  The  basic  data  structures  and  stale  transitions  are  functionally  equivalent  to 
FTLO,  with  some  modifications.  In  ot6a  to  make  use  of  the  satellite  software  q)ecified 
in  Appendix  A,  die  coneqionding  ground  station  software  must  be  developed  which  will 
produce  packets  in  the  proper  ftmnat  to  be  interixeted  by  PANSAT.  Thoefore,  the  bit- 
levd  structure  of  die  ground  statiofi  packets  is  described  bdow,  as  well  as  the  premier 
ground  inteqnetation  of  the  packets  originating  on  the  satellite. 


B.  PACKET  FORMAT 

Eadi  packet  to  be  transmitted  consists  of  an  informadm  field  of  0  to  2047  bytes, 
preceded  by  a  two  byte  header.  The  header  identifies  the  type  of  peck^  and  indicates 
the  number  of  bytes  in  the  information  field.  The  packet  structure  is  defined  as  follows 
in  the  stdtware  specification: 

PacketJType  « record 


length Jsb: 

uchar; 

hi: 

uchar; 

info: 

Pdata; 
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This  Amctttie  indicates  that  the  header  portion  of  the  packet  oonasts  of  the  two  unsigned 
duoaden  (octets)  ’length_lsb’  and  *hl*.  The  inftmnatioo  fteld  is  given  the  type  ’Pdata', 
whidh  is  defined  in  die  iqiecification  as  an  array  of  0  to  2047  unsigned  diaracters.  Since 
diis  is  a  variable  length  array,  its  length  must  be  indicated  in  die  header. 

The  octet  ’length_lsb*  contains  die  least  dgnificant  8  bits  of  the  data  length.  The 
octet  *hl’  contains  die  3  roost  significant  bits  of  the  data  length,  as  well  as  an  indicadroi 
of  the  type  of  packet  The  bits  of  ’hi’  ate  labded  *76543210*.  Bits  7-S  are  the  3  most 
significant  bits  of  the  data  length,  and  must  be  jnqiended  to  the  *length_lsb*  to  give  the 
full  length  of  the  informatitMi  fidd.  Bits  4-0  of  *hl*  provide  a  number  from  0  to  31. 


This  number  is  decoded  into  packet  type  as  indicated  in  Table  6.1. 


TABLE  6.1  PACKET  TYPES  | 

PMket  Nambm: 

Specification  Constant 

1  Packet  Name 

0 

data 

Data 

1 

datajsnd 

Data  End 

2 

login jtsp 

Login  Re^nse 

3 

i^loadjcmd 

Upload  Command 

4 

uljgo_resp 

Upload  Go  Response 

5 

ul_error_resp 

Upload  Error  Re^nse 

6 

tdjtckjresp 

Upload  Acknowledged  Response 

7 

tUjiakjesp 

Upload  Not  Acknowledged  Response 

8 

downloadjmd 

Download  Command 

9 

dl_error_resp 

Download  Error  Response 

10 

dljtborted_resp 

Download  Aborted  Response 

11 

dljxjmpletedjTsp 

Download  Completed  Response 
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TABLE  tf.1  PACKET  TYPES 


_ table  6.1  PACKET  TYPES _ I 

Picket  Niimbor 

1  Specification  Constant 

1  Packet  Name 

12 

tUjtdcjand 

Download  Acknowledged  Command 

13 

dljuikjand 

Download  Not  Acknowledged 
Command 

14 

dirjthortjcmd 

Directory  Short  Command 

15 

dirjongjmd 

Directory  Long  Command 

16 

selectjcmd 

Select  Command 

17 

selectjresp 

Select  Response 

18-29 

reserved 

30 

deljcmd 

Delete  Command 

31 

deljresp 

Delete  Response 

The  ground  software  and  satellite  software  are  peer  entities  at  this  level,  rather  than 
master  and  slave.  However,  since  the  ground  must  initiate  all  data  exchanges,  with  the 
satellite  acting  as  a  server  responding  to  requests  made  from  the  ground,  the  identifier 
’cmd’  is  used  to  indicate  paclmts  originating  from  the  ground,  while  *resp*  indicates 
packets  sent  from  the  satellite.  The  data  and  datajend  packets  can  originate  from  either 
the  ground  station  or  the  satellite.  Explanations  of  each  of  the  packet  types  and  the 
contents  of  their  information  fields  are  given  in  the  following  sections. 

C.  THE  DATA  AND  DATA  END  PACKETS 

Any  file  to  be  transmitted,  either  from  the  ground  or  from  the  satellite,  will  be 
broken  up  into  an  appropriate  number  of  data  packets,  depending  on  its  length.  The 
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infonnatioii  fidd  of  ndi  data  packet  will  be  the  bytes  from  the  file  to  be  transmitted. 
Bits  4-0  of  the  ’hi*  field  of  the  packet  header  will  be  ’00000*,  identifying  the  packet  as 
containing  file  data  in  its  information  field.  Bits  7-5  of  ’hi’  and  the  octet  ’lengthjsb’ 
will  together  indicate  the  numbtf  of  bytes  of  file  data  being  transmitted  in  this  packet. 
The  transmission  of  the  end  of  the  file  will  be  indicated  by  sending  a  datajtnd  i»cket 
immediatdy  after  the  transmission  of  the  last  data  packet.  The  datajend  packd  has  no 
’info’  field. 

Bit-level  examples  of  the  various  packet  types  will  be  given  in  Tables  6.2A  through 
6.2S.  In  these  examples,  O’s  and  I’s  will  be  shown  where  particular  bit  patterns  must 
be  used.  Where  arbitrary  bit  patterns  may  be  present,  other  symbols  will  be  used.  The 
intoided  meanings  of  these  symbols  will  be  made  clear  in  the  "interpretation”  section  of 
each  table. 


1  TABLE  6,2A  EXAMPLE  OF  A  <fola  PACKET  | 

hi 

info 

LLLLLLLL 

dddddddd 
dddddddd  ... 

• 

Interprdation 

low  order  bits  of 
the  data  length 

HHH  —  high  order  bits  of  the  data  length. 
’00000’  =  data  packet. 

ftle  data  in 
bytes 
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TABLE  tf OB 

EXAMPLE  OF  A  datajuui  PACKET 

hngth^lsb 

|hi 

000  00001 

1  Intarprelatkm  | 

1  no  info  field 

’OOOOr  s  datajend  packet.  | 

D.  THE  LOGIN  RESPONSE  PACKET 

Ndth^  the  FTLO  protocol  of  Ward  and  Price,  nor  the  packet  transfer  protocol 
specified  here,  has  an  explicit  Login  Command  packet.  A  login  request  from  the  user 
is  made  implicitly  whenever  a  data  link  is  established  between  the  ground  station  and  the 
satellite  on  the  lower,  AX.2S,  data  transfer  levd.  When  the  AX.2S  protocol  software, 
BAX,  recognizes  a  "connection  request*  frame  from  a  new  user,  it  informs  the  satellite 
data  transfer  module.  The  data  transfer  module  tells  BAX  whether  to  accept  the 
cminection  or  not.  If  the  connection  is  accepted,  BAX  sends  the  "accept  connection* 
frame  to  the  ground  user,  and  the  data  transfer  module  informs  the  packet  transfer 
module  that  a  data  link  has  been  established.  At  this  point,  the  satellite  packet  transfer 
protocol  calls  for  the  transmission  of  a  Login  Response  packet. 

The  purpose  of  the  login_resp  packet  is  to  inform  the  user  of  the  time  onboard  the 
satellite  when  the  data  link  is  established.  The  login_resp  packet  also  has  a  one  byte 
login  flag.  This  flag  indicates  whether  the  user  currently  has  an  active  selection  list 
(explained  below)  and  whether  the  satellite  requires  Pacsat  file  headers.  The  Pacsat  file 
header  was  ^eloped  by  Jeff  Ward  and  Harold  Price  for  use  with  their  Pacsat  Protocol 
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Suite,  which  includes  FTLO  [Ref.  8].  A  PANSAV  file  header  has  been  developed  which 
does  not  nuitch  the  Pacsat  file  header  of  Ward  and  Price,  and  so  the  login  flag  in  the 
loginjtsp  packet  will  always  indicate  that  Pacsat  file  headers  are  not  required. 
PANSAT  file  headers  will  always  be  requited  for  files  uploaded  to  PANSAT.  The 
information  field  of  the  loginjresp  packet  includes  a  4-byte  unsigned  int^er  indicating 
the  login  time  (the  number  of  seconds  since  January  1,  1970),  followed  by  a  1-byte  login 
flag.  Thus,  the  information  length  indicated  by  the  header  must  be  S.  Bits  7-4  of  the 
login  flag  will  be  ’0000’.  Bit  3,  the  ’s’  bit,  will  be  ’1’  if  the  client  already  has  an  active 
selection  list,  and  will  be  ’0’  if  not.  Bit  2  will  be  ’O’,  indicating  that  Pacsat  flle  headers 
are  not  used.  Bits  1  and  0  indicate  the  protocol  versitm  number.  They  will  be  ’(X)’  in 
the  case  of  the  protocol  spedfled  in  Appendix  A. 


1  TABLE  6^C  EXAMPLE  OF  A  ibgiii_rv^  PACKET  | 

lengtti_lsb 

hi 

Info  I 

00000101 

000  00010 

tttttttt  tttttttt  tttttttt  tttttttt 

1  Interpretation  | 

5  bytes  in 
info  fidd 

loginjresp 

packet 

4  byte  login  time  | 

login  flag:  ’s’  =  ’1’  indicates  active  selection  list  | 

E.  THE  UPLOAD  COMMAND,  UPLOAD  GO  RESPONSE,  AND  UPLOAD 
ERROR  RESPONSE  PACKETS 

Before  uploading  a  file  to  the  satellite,  the  client  software  must  first  detnmine 
whether  there  is  room  in  the  mail  box  and  if  the  satellite  will  accept  the  upload.  To 
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make  determiiiation,  the  ground  ittatkm  tn^  The  satdlite  will 

iWfKXid  with  die  ul_g,ojtsp  if  the  upload  will  be  allowed  and  with  the  ul_envr_resp  if 
not. 

The  information  fidd  of  the  uploadjmd  contains  a  4-byte  file  numbo’  followed  by 
a  4-byte  file  length.  If  this  is  the  first  request  to  upload  a  particular  file,  the  file  number 
must  be  *0x00000000’.  The  file  length  must  be  the  actual  length  of  the  file  which  is 
intended  for  upload,  including  the  PANSAT  file  header,  which  must  be  piqiended  to 
each  file.  When  the  satellite  receives  the  uphadjcmd,  it  will  determine  if  there  is  room 
for  a  file  of  the  indicated  lotgth.  If  there  is,  the  ul_go_resp  will  include  a  file  number 
to  be  assigned  to  the  file  in  the  mail  box  aboard  the  satellite.  Whoi  the  client  receives 
this  file  number,  it  may  be  placed  in  the  PANSAT  file  header  before  upload.  If  the 
client  does  not  place  the  pr(q)er  file  number  in  the  PANSAT  file  header  before  upload, 
then  that  field  must  contain  all  O’s  and  the  satellite  will  make  the  correction  once  the  file 
has  been  successfully  uploaded. 

If  the  upload  request  is  for  the  continuation  of  a  previously  interrupted  upload,  the 
uphadjcmd  must  contain  the  actual  file  number  previously  assigned  by  the  satellite.  The 
file  loigth  must  still  indicate  the  full  length  of  the  file,  regardless  of  how  much  of  the 
file  was  previously  uploaded.  If  the  satellite  can  accqpt  this  continued  upload,  the 
ul_go_resp  will  include  the  offset  at  which  the  client  should  begin  the  transmission  of 
the  file.  To  determine  this  offset,  the  satellite  simply  inspects  its  partial  copy  of  the  file 
to  see  how  many  bytes  it  has  previously  received.  The  complete  information  field  of  the 
ul_go_resp  includes  the  4-byte  file  number  either  newly  or  previously  assigned  to  the 
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file,  firilowed  by  the  4-byte  file  offset.  If  no  part  of  the  file  has  beoi  previously 
uploaded,  then  the  indicated  offs^  will  be  *0’. 


If  diere  is  no  room  for  the  file,  if  the  uphadjcmd  includes  a  non-zno  file  number 
Miiich  does  not  correqmnd  to  any  file  onboard  the  satellite,  or  if  the  satdlite  determines 
that  iqrtoad  of  the  indicated  file  has  already  been  completed,  then  an  uljsrrorjresp  is 
transmitted  rather  than  an  uljsojtsp.  The  ul_em>r_resp  has  a  1-byte  information  fidd 
which  simply  indicates  one  of  several  possible  error  conditions.  The  possible  mors 
associated  with  an  upload  command  and  their  corresponding  bit  patterns  are  indicated  in 


Table  6.3A. 


TABLE  6.3A  ERROR  CODES 


Bit  Pattern 

Error  Code 

00000001 

erJU Jormedjynd 

00000010 

erjHidjcominue 

00000100 

erjiojsuch Jilejumiber 

00001100 

er Jilejcomplete 

00001101 

er  no  room 

The  meanings  of  most  of  these  error  codes  are  obvious  from  their  names.  The 
code  er_badj:ontinue  is  issued  when  the  file  number  in  the  uploadjcmd  is  non-zero  but 
the  file  length  in  the  uploadjcmd  does  not  agree  with  the  file  length  stored  in  the 
PANSAT  header  of  the  partially  uploaded  file. 
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TABLE  6 JD 


OF  upload jemd  PACKETS 


EXAMPLES 


info 


00001000 


000  00011 


1JLTJ.LLL  U.LU.I JJ.  LUJXIJ.T.  LLLLLLLL 


00001000 


000  00011 


nnnnniinn  nnnnnnnn  nnnnnnnn  nnnnnnnn 
LIXIJXLL  LLLLLLLL  LLLLLLLL  LLLLLLLL 


Intenn^tions 


8  bytes  in 
info  field 


ipload_ 
and  packet 


New  upload  -  unknown  file  number 
4  byte  file  length 


8  bytes  in 
info  field 


upload_ 
and  packet 


4  byte  file  number 
4  byte  file  length 


1  TABLE  6^E  EXAMPLE  OF  AN  ii/ _go_n^  PACKET  | 

hi 

info  1 

00001000 

000  00100 

nnnnnnnn  nnnnnnnn  nnnnnnnn  nnnnnnnn  j 

OOOOOOOO  00000000  00000000  oooooooo  1 

1  Interpr^tion  j 

8  bytes  in 
info  field 

ul_go_resp 

packeF 

4  byte  file  number  1 

4  byte  file  offset  at  which  to  begin  upload  | 

TABLE  EXAMPLE  OF  AN  PACKET 


kogth.Ui 

Iw 

info 

00000001 

000  00101 

1  InterpretatioD  | 

1  1  byte  in  info  field 

uljerror^resp 

1  byte  errmr  code  | 

F.  THE  UPLOAD  ACKNOWLEDGED  RESPONSE  AND  UPLOAD  NOT 

ACKNOWLEDGED  RESPONSE  PACKETS 

When  the  clioit  software  on  the  ground  receives  an  uljgojtsp  from  the  satdlite, 
it  will  commence  to  upload  the  file  in  a  series  of  data  packets,  starting  with  the  byte  of 
the  file  indicated  by  tlui  offset  in  the  ul_go_resp.  Once  the  data  packet  containing  the 
last  byte  of  the  file  has  beat  transmitted,  the  datajend  packet  must  be  sent.  After 
receiving  the  datajend  packet,  the  satellite  will  check  the  integrity  of  the  file,  as  will  be 
explained  in  Clu^to’  vm.  If  the  file  passes  all  checks  and  is  successfully  stored  aboard 
the  satdlite,  an  uljadcjresp  will  be  transmitted  to  the  user.  If  the  file  is  found  to  be 
defective,  an  uljudcjtsp  is  transmitted  instead  and  the  file  is  discarded.  The  satellite 
will  rraiember  the  file  number,  however,  so  that  the  user  can  later  attempt  another 
upload  of  the  same  file. 

The  uljickjresp  has  no  informaticm  field.  The  uljiakjvsp  has  a  1-byte 
information  field  which  consists  of  one  of  the  error  codes  of  Table  6.3B. 
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TABLE 

IB  1BB<»  CODES 

Bit  Phtteni 

1  Error  Code 

00001101 

erjiojvom 

00001110 

er_badjieader 

00001111 

erjieader_d»eck 

00010000 

erjfodyjdtedc 

The  er_bad_header  code  is  sent  when  the  PANSAT  file  header  is  missing,  incomidete, 
or  inomxect.  The  code  for  er_header_check  is  sent  when  the  checksum  cm  the  heada 
fiuls  and  erjbodyjaheck  is  sent  when  the  checksum  on  the  file  body  fails. 

An  idjiakjtsp  may  also  be  sent  by  the  satellite  before  a  data_end  packet  is 
received  if  the  satellite  needs  to  tnminate  die  upload  for  any  reason.  If  the  ground 
station  lecdves  an  uljuikjesp,  it  should  immediately  stop  sending  data  packets,  and 
transmit  a  datajaid  packt^  if  it  has  not  already  done  so. 


1  TABLE  6  JG 

EXAMPLE  OF  AN  «/_ack_/vJSp  PACKET  | 

length.ltib 

hi 

000  00110 

1  InteriMretatioD  | 

1  no  info  field 

idjtckjtsp  1 
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G.  THE  DOWNLOAD  COMMAND  PACKET 

PricMr  to  using  downloadjmd  packets  to  request  files  to  be  downloaded  from 
PANSAT,  the  client  must  establish  an  active  sdecdon  list  ofU)oard  the  satellite.  This  is 
achieved  by  using  the  selectjcmd  which  is  mcplained  below.  Once  the  client  has  used 
die  sdecdon  list  to  begin  downloading  a  file  or  to  obtain  file  directories  (see  Directory 
Omunands  below),  the  selection  list  need  not  ranain  active  to  cmtinue  downloading,  as 
long  as  the  client  knows  the  file  numb<»r  for  each  file  requested. 

Each  downloadjmd  packet  is  used  to  request  a  single  file.  The  information  field 
of  this  packet  contains  the  4-byte  file  numbn  for  the  file  requested  followed  by  the  4- 
byte  file  offset  from  which  transmission  of  the  file  should  begin.  In  FTLO,  a  file  number 
of  ’QxOOfXXXXX)’  is  used  to  indicate  the  next  file  in  the  active  selection  list,  proceeding 
from  newer  files  toward  older  files,  while  *OxFFFFFFFF’  requests  the  next  file  in  the 
list  proceeding  from  older  files  toward  imwer  files.  In  the  current  packet  transfer 
specification  for  PANSAT,  both  ’Ox(X)000000*  and  ’OxFFFFFFFF’  will  result  in 
requesting  die  next  file  in  the  active  sdection  list  proceeding  from  older  files  toward 
newer  files.  I  iie  actual  file  number  of  the  file  requested  is  known,  then  this  number 
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is  piaoed  in  the  dtmrioadjcmd  packet  The  file  oiba.  should  be  *0*  if  this  is  a  new 
downlond  request,  and  should  indkaSe  the  byte  nundMsr  ftmn  irfiidi  to  proceed  if  this  is 
a  download  continuation. 


TABLE  6,21  EXAMPLES  OF  download  emd  PACKETS 


length^kb 


hi 


info 


00001000 


000  01000 


I » » I  • » » iiri  •  •  1 1 1  III  r»n 


1 1 1 1 1 1 1  III  i;i  I  I  I  riii  i;i;i;i;i;i;iii;i;i;i;i;i;i:i 


00001000 


000  01000 


11111111  11111111  11111111  11111111 


I  I  I  I  i.i  i.iii  1 1 1 1 1 1  III  1 1 1 1 1 1  III  1 1 1 1 1 1 1 


00001000 


000  01000 


nnnnnnnn  nnnnnnnn  nnnnnnnn  nnnnnnnn 
00000000  00000000  00000000  00000000 


Inter|n«tathHis 


8  bytes  in 
info  field 

download_ 

and 

requesting  next  file  in  sdect  list 
b^in  download  at  b^inning  of  file 

8  bytes  in 

download_ 

requestmg  next  file  in  select  list 

info  field 

and 

b^in  download  at  b^inning  of  file 

8  bytes  in 

download^ 

file  number  of  requested  file 

info  field 

and 

file  offset  at  which  to  begin  download 

When  requesting  the  "next"  file  in  the  selection  list,  the  offset  should  always  be 
’O’,  since  this  should  only  be  used  to  request  a  new  file.  Once  a  download  has  been 
interrupted  and  subsequrotly  continued,  the  file  number  should  already  be  known,  and 
this  information  as  well  as  the  offset  should  be  used  in  the  download_and.  If  the  file 
offset  indicated  by  the  ground  station  is  equal  to  or  greater  than  the  length  of  the  file 
stored  on  the  satdlite,  no  error  is  groerated.  Instead,  the  satellite  transmits  a  datajend 
pdcket  immediatdy,  with  no  preceding  data  packets. 
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H.  THE  DOWNLOAD  ERROR  RESPONSE  PACKET 


When  the  setefliie  receives  a  properiy  formatted  danmdoadjmd  whidi  it  is  able  to 
reqnnd  to,  it  immediaiely  begins  downloatUi^  foe  file  in  a  series  of  data  packets.  Once 
the  last  foe  file  has  been  tnnsmitted.  the  satellite  sends  a  data_end  packet.  If, 
however,  the  satellite  cannot  service  foe  downtoadjmd  far  any  reason,  it  will  transmit 
a  dljsrrorjt^  pocket. 

The  dljerrorjesp  information  field  consists  of  a  1-byte  error  code.  The  possible 
mors  are  sbmvn  in  Table  6.3C. 


1  TABLE  6  JC  ERROR  CODES  | 

Bit  Fatteni 

1  Error  Code 

00000100 

erjio_such JUejmnber 

00000101 

erjekctionjanpty 

The  code  erjiojudi  JUejuanber  is  used  if  a  qiecific  file  has  been  requested,  the  file 
number  of  which  is  not  found  in  the  mail  box.  The  code  erjelectionjanpty  is  used 
when  the  "next*  file  is  requested,  but  the  user  currently  has  no  active  selection  list.  The 
specification  for  FTLO  also  includes  error  codes  dealing  with  file  forwarding  c^xibilities 
whidt  are  not  implemented  on  PANSAT.  These  codes  are  included  in  the  specification 
of  Appendix  A  for  the  sake  of  completicm,  to  ensure  they  will  not  be  used  for  any 
PANSAT  ^wcific  definitions.  They  will  not  be  included  in  any  dljtrrorjesp  packets 
from  PANSAT,  however.  These  FTLO  error  codes,  unused  by  PANSAT,  include 
erjdftady Jacked  and  erjio_such_destination. 
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1  TABLE  iJI  EXAMPLE  OF  A  dr.crror.i«9  PACKET  | 

kaftt  hb 

[w _ 

Info 

00000001 

000  01001 

1  byte  infi>  field 

dl_errorjtsp  1  byte  errOT  code  | 

I.  THE  DOWNLOAD  ACKNOWLEDGED  COMMAND,  DOWNLOAD 
COMPLETED  RESPONSE,  DOWNLOAD  NOT  ACKNOWLEDGED 
COMMAND,  AND  DOWNLOAD  ABORTED  RESPONSE  PACKETS 
When  the  client  software  recdves  a  datajnd  packet  from  the  satellite,  it  knows 
the  downloaded  file  is  complete.  It  performs  any  desired  integrity  checks  on  the  file 
(such  as  diecldng  header  and  body  check  sums)  to  determine  whether  the  download  was 
completed  successfully.  If  the  file  has  been  received  satisfactorily,  the  ground  station 
must  transmit  a  dljackjynd.  The  satellite  responds  to  a  dl_ack_and  with  a 
^jxmpUtedjesp  to  end  the  download  process.  If  the  ground  software  does  not  find 
the  downloaded  file  to  be  satisfactory,  it  transmits  a  dljiakjand,  to  which  the  satellite 
reqxmds  with  a  dljibortedjtsp. 

In  the  FTLO  qwcificadon,  the  information  field  of  the  dljickjml  consists  of  a  one 
byte  ’r^sterjdestination’.  This  informaticm  is  used  by  a  Pacsat  to  complete  some  of  the 
fite  forwarding  opnations  which  are  not  implemented  by  the  current  PANSAT  software 
q)ecification.  Therefore,  the  information  field  is  not  necessary  in  a  dl_ack_cmd  sent  to 
PANSAT,  and  it  will  be  ignored  if  it  is  included.  This  single  byte  of  information  may 
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be  adneed  for  use  by  PANSAT  at  a  later  (fato.  The  dljxm^^etedjt^  transmitted  by 
dm  Sildlile  hu  im  infmation  fidd.  Thed!?_nai^_cmdaiiddmd!(_.abomd_fe^ 
have  no  infomudion  fidds. 
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TABLE  iJN  EXAMPLE  OF  A  a jA0rUd_,rnp  JACKET 


J.  THE  DIRECTORY  COMMAND  PACKETS 

FTLO  i9)ecifies  two  directory  commands,  the  dir_short_cmd  and  the  dirJong_and. 
For  PANSAT,  there  is  only  (xie  directory  command,  and  either  of  these  two  packet  types 
will  invoke  it.  The  results  of  each  command  will  be  exactly  the  same.  The  infixmation 
field  of  a  dtrjcmd  is  a  4-byte  file  number.  This  number  indicates  the  file  for  which  a 
diiectoiy  oitry  is  requested.  A  directory  entry  consists  of  the  PANSAT  file  header  from 
die  file  of  interest.  From  this  file  header,  the  ground  station  software  can  determine  any 
necessary  information  about  the  file.  The  user  can  decide  from  this  information  whether 
to  request  the  file  for  download. 

In  FTLO,  a  file  number  of  ’0x00000000’  is  used  to  request  the  directory  entries  for 
the  next  10  files  in  the  active  selection  list,  proceeding  from  newer  files  toward  older 
files,  while  ’OxFFFFFFFF’  requests  the  next  10  file  directories  proceeding  from  older 
files  toward  newer  files.  In  the  current  packet  transfer  specification  for  PANSAT,  both 
’0x00000000’  and  ’OxFFFFFFFF’  will  result  in  requesting  entries  for  the  next  10  files 
in  the  active  selection  list  proceeding  from  older  files  toward  newer  files.  If  the  client 


lya  no  cunentfy  active  adection  lid,  dieo  a  d&itctory  entry  can  only  be  requested  a 
file  for  which  the  file  number  is  already  known. 

When  foe  aldlite  receives  a  oonectly  fOTmatted  dirjynd  which  it  can  teqxmd  to, 
it  sends  foe  requested  information  down  in  a  data  packet.  Since  PANSAT  file  headers 
are  at  most  200  bytes  long,  10  of  them  will  fit  in  a  single  packm.  Thus,  after  mm  data 
packet  is  transmitted,  a  data^end  packet  will  immediately  be  sent.  If  foe  sa^lite  is 
unable  to  reqiood  to  the  dirjand,  it  will  send  a  dl_errorjtsp  indicating  the  reason.  The 
error  diaracter  contained  in  this  packd  will  be  either  er_selectionjanpty  or 
erjio_sudt JUejaanber. 


TABLE  6  JO  EXAMPLES  OF  diir  amf  PACKETS 


kagdijsb 


hi 


info 


I  III  I 


100 


000  01110 


00000100 


000  01111 


11111111  11111111  11111111  11111111 


00000100 


000  01111 


nnnnnnnn  nniuinnnn  nnnnnnnn  nnnnnnnn 


Interpretations 


4  bytes  in 

dir  short 

requesting  directory  oitries  for  next  10  files  in 

info  field 

and 

sdect  list 

4  bytes  in 

dirJong_ 

requesting  directory  entries  for  next  10  files  in 

info  fidd 

and 

select  list 

4  bytes  in 

dirJong_ 

file  number  of  file  for  which  directory  mitry  is 

info  fidd 

and 

requested 
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K.  1HBSEE2CTa)iAlANDiU«iDmECTRESK>ICT  PACKETS 


The  sekct_cmd  is  the  means  by  which  the  user  deagnates  files  to  be  jdaced  in  an 
active  selection  list  onboard  the  satellite.  Once  diis  list  has  been  established,  it  can  be 
used  to  request  file  directmies  or  files  fiv  download.  The  seieajcmd  qwcified  by  FTLO 
assumes  use  of  Pacsat  file  headers  in  its  structure.  A  diffment  selectjynd  structure  is 
qiedfied  here,  which  is  based  upon  the  PANSAT  file  headtf .  This  structure  is  related 
to,  but  not  exactly  the  same  as,  the  selectjmd  specified  by  Price  and  Ward  [Ref  1.]. 

Once  a  selea_cmd  is  recognized,  if  it  is  not  in  the  PANSAT  structure  ^)ecified 
here,  then  a  default  selection  list  will  be  compiled.  This  list  will  be  comprised  of  all 
mail  addressed  to  the  requesting  user  which  has  not  been  previously  downloaded,  all 
builds  and  user-accessible  tdemetry  and  messages  addressed  to  "all" .  The  satellite  will 
send  a  selectjresp  packet  to  the  user.  The  information  field  of  this  packet  consists  of  a 
two  byte  integer  which  indicates  the  number  of  files  in  the  selection  list. 

If  the  PANSAT  select  structure  is  used,  the  selection  list  will  be  assembled 
according  to  the  selection  criteria  contained  in  the  sekctjmd.  If  the  satellite  can 
interpret  the  setectjmd  and  compile  the  corresponding  selection  list  it  will  transmit  the 
selectjresp  packet.  In  this  case,  the  two  byte  integer  in  the  information  field  indicates 
the  number  of  files  matching  the  selection  criteria.  An  active  list  consisting  of  those  file 
numbers  will  be  maintained  aboard  the  sidellite.  If  the  select jcmd  appears  to  be  in  the 
PANSAT  fonaat  but  cannot  be  successfully  parsed  by  the  satellite  software,  then  a 
dl_errorjesp  is  transmitted  with  the  error  code:  00001000  er jworly Jbrmedjel 
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The  sekajMd  has  a  variable  length  infonnation  field.  The  inftmnation  contained 
in  die  fidd  consists  of  a  PANSAT  qiecific  flag,  die  number  of  selection  critoia  i»esent, 
and  die  criteria  themsdves.  The  selection  criteria  are  combined  with  each  odio’  using 
the  operaton  and  and  or,  forming  a  restricted  type  of  postfix  logical  equation.  In  this 
postfix  equation,  each  logical  operator  is  preceded  by  its  two  operands.  The  first  two 
selection  criteria  are  combined  logically,  according  to  the  first  operator,  to  form  the 
single  operand  true  or  false.  This  operand  is  then  followed  by  another  selection  and 
another  operator.  The  second  (qierator  combines  the  two  operands  preceding  it  to  form 
a  single  operand.  The  process  is  continued  until  the  last  logical  operator  present,  which 
will  be  the  last  component  of  the  equation,  has  be«i  used  to  combine  its  two  operands. 
The  result  will  be  a  single  value  of  true  or  false.  Each  file  for  which  the  selection 
equation  yields  a  value  of  true  will  have  its  file  number  added  to  the  active  selection  list 
aboard  the  satellite. 

The  first  byte  of  the  select jmd  information  field  should  be  ’OxFF’,  a  flag 
indicating  that  the  selectjmd  is  in  the  PANSAT  format,  ^pon  recognizing  this  flag,  the 
satellite  will  attempt  to  translate  the  selectjmd  into  the  appropriate  logical  equation.  If 
this  flag  is  not  present,  the  default  selection  list  described  above  will  be  compiled  and  the 
remainder  of  the  select  structure  will  be  discarded. 

The  second  byte  in  the  infonnation  field  is  an  unsigned  integer  indicating  the 
number  of  selection  criteria  contained  in  the  remainder  of  the  structure.  The  selection 
criteria  can  be  defined  as  follows: 
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lelop: 

udiar; 

headerjtem: 

udiar; 

item  Jen: 

uchar; 

cmnparejtem: 

array[item Jen]  of  uchar; 

end; 


Bit  ’7'  of  the  one  byte  ’leli^'  (relational  operator)  must  always  =  ’O’.  Bits  ’654’ 
have  the  interpretations  shown  in  Table  6.4,  and  bits  ’3210’  are  translated  as  indicated 
in  Table  6.5.  Tb^  ’headerjtem’  idoitifies  which  item  in  the  PANSAT  file  hesdet  to 
compare  the  ’compare_item’  with.  The  one  byte  ’headerjtem’  is  decoded  as  Table  6.6 
indicates. 


1  TABLE  6.4  BITS  *654’ OF  THE  RELATIONAL  OPERATOR  | 

Bits  654 

Relation 

000 

equal  to 

001 

greater  than 

010 

less  than 

oil 

not  equal  to 

100 

greater  than  or  equal  to 

101 

less  than  or  equal  to 

1  TABLE  6.5  BITS  *3210’ OF  THE  RELATIONAL  OPERATOR  | 

Bits  3210 

Interpretation  of  ’cmnparejtem’ 

Notes 

0000 

Multi-byte  unsigned  integer 

’item  len’  must  equal  1, 

2  or  4. 

0011 

Array  of  characters,  convert  to  lower 
case  before  comparison 

Valid  only  with  Bits 
’654’  =  ’000’  or  ’011’ 
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1  TABLE  6.6  HEADER  ITEMS  j 

1  *hMider_itcm*  Bit  FiUteni 

1  CoiKt 

1  Name  of  Header  Field 

ft 

Flag 

00000010 

mn 

Mail  Number  (File  Number) 

00000110 

ml 

Mail  Length 

00001010 

ft 

File  Type 

00001011 

a 

Compression  Type 

00001100 

bo 

Body  Offset 

00001110 

dc 

Download  Count 

00001111 

sc 

Source  Call  Sign 

00010101 

pr 

Priority 

00010110 

lU 

Upload  Time 

00011010 

et 

Expire  Time 

00011110 

na 

PANSAT  File  Name 

00100110 

ex 

PANSAT  File  Extension 

00101001 

nd 

Number  of  Destinations 

00101010 

ds 

Destination  Call  Signs  or  Path 

01010100 

ti 

Tide 

01110100 

kw 

Keywords 

The  short  integers  formed  by  the  ’headerjtem’  bit  patterns  correspond  to  the 
normal  byte  offsets  within  the  PANSAT  file  header  of  the  beginning  of  each  of  the  listed 
header  fields.  This  is  useful  in  other  areas  of  the  software  specification. 

The  one  byte  integer  ’itemjen’  gives  the  byte  length  of  the  last  item  in  the 
’selection’,  the  ’compare Jtem.  ’  The  compare  item  is  interpreted,  as  indicated  by  the 
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*itlO|»\  is  ddwr  m  unsifMd  one,  two  or  four  byte  integer,  or  an  army  td  dtanicters. 
The  relational  operation  specified  by  the  *rek)p'  is  perfwmed  between  the  designated 
header  item  and  die  ocmipare  item.  If  die  reladon  ’header Jtem*  'lelop*  ’compare Jtem’ 
is  satisfied,  dien  diis  sdecdon  equatfon  is  evaluated  as  true. 

If  the  user  has  only  one  criteria  for  selection,  the  Select_Structure  can  end  after  just 
one  ’selecdon’.  The  user  may,  however,  specify  multiple  sdecdon  criteria.  Fot  this 
purpose,  die  bit  patterns  for  logical  operabns  are  defined  as  in  Table  6.7. 


1  TABLE  6.7  LOGICAL  OPERATORS  | 

*logop’  Bit  Pattern 

Logical  Operation 

10000000 

and 

11100000 

or 

A  completed  Sdect_Structure  may  a^ipear  as  follows: 

QxFF  num  jeUctions  selection  selection  lofop  selection  losop  selection  toeon.etc. 

When  ’equal  to’  string  comparisons  are  made  between  ’comparejtems’  and  certain 
header  fields,  the  comparison  is  defined  as  successful  if  the  ’comparejtem’  string  is 
found  anywhere  within  the  header  item  string.  In  these  same  fields,  a  ’not  equal  to’ 
comparison  is  successful  if  the  ’compare_item’  string  is  not  found  anywhere  within  the 
header  item  string.  Header  fidds  for  which  this  applies  are  the  "Title”  and  "Keywords" 
fields.  This  can  also  apply  to  the  destination  fields  under  certain  circumstances,  which 
will  be  elaborated  on  below. 
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To  indicate  that  a  file  is  addressed  to  "all”,  the  source  places  the  number  ’0x00’ 
in  the  "Number  of  Destmations"  field,  and  die  following  7  "Destination*  fields  are  left 
out  of  die  header  cmnidetely.  A  one-byte  int^er  comparison  betweoi  the  "Number  of 
Destinations*  field  and  the  number  ’0x00’  can  determine  that  a  file  is  addressed  to  all 
users.  When  there  are  between  1  and  7  individual  destination  call  signs,  this  number  is 
idaced  in  the  "Number  of  Destinations*  field,  and  the  jyipropriate  numbm'  of 
"Destination*  fields  are  included.  To  find  files  \iMch  are  addressed  to  a  specific  user, 
a  string  comparistm  can  be  made  between  a  6-byte  call  sign  as  the  ’comparejtem’  and 
die  header  item  "Destination  Call  Signs  or  Path".  This  header  item  refers  to  all 
"Destination"  fields  present.  The  satellite  will  compare  the  designated  call  sign  to  each 
destination  listed,  and  the  comparison  will  be  successful  if  a  match  is  found  with  any  of 
them. 

It  may  be  that  the  user  wishes  to  designate  an  audience  for  the  file  which  is  broader 
than  7  individual  call  signs  but  narrower  than  "all"  users  in  the  world.  In  order  to 
achieve  this,  the  user  places  the  number  ’0x08’  or  the  number  ’0x09’  in  the  "Number  of 
Destinatitms"  fidd,  and  all  7  "Destination"  fields  are  then  included  as  a  single  42-byte 
array.  In  this  combined  field  can  be  placed  information  to  further  define  the  audience 
for  which  the  file  is  intended.  If  the  "Number  of  Destinations"  is  ’0x08’,  then  the  file 
is  addressed  to  "all",  and  the  source  has  included  path,  location  or  other  information 
about  himself  in  the  following  "Path"  field.  If  the  "Number  of  Destinations"  is  ’0x09’, 
then  the  source  has  included  further  information  about  the  intraded  audirace  in  the 
following  "Path"  field.  Users  may  use  this  information  in  selectjmds,  in  which  case 
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•ny  *ooin|Mue_item*  will  be  leaidied  for  anywhere  within  the  "PfOh”  field.  The  header 
item  to  use  widiin  the  ’selection*  will  again  be  "Destination  Call  Signs  or  Path”,  but  this 
time  die  satellite  will  look  fcv  any  matdiing  string,  not  simply  matdung  6^yte  call  signs. 
Source  destination  padi  information  can  probably  better  be  used  by  ground  software 
as  the  result  of  dirjmdSt  in  which  case  the  software  can  present  the  user  with  any 
information  which  may  hdp  the  user  in  choosing  individual  files  to  download. 
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TABLE  6 JP 


OF  seUet  emd  PACKETS 


9  bytes  in 
info  fieki 


sdeajmd 


2S  bytes  in  seleajynd 
info  field  packet 


PANSAT  seleajmd  flag,  1  ’selection’ 

’idop’  -  greater  than  a  multibyte  unsigned  int^ear 
’header Jtmn’  -  Ujrioad  Time 
4  byte  ’oHnpareJtem’  -  last  login  time 

( This  command  requests  all  files  which  wore 
uploaded  aftm‘  die  user’s  last  login  time.) 


PANSAT  select jand  flag,  3  ’sdections’ 

’idop’  -  equal  to  an  array  of  characters 
’heatojtem’  -  Keyword 
4  characters  in  the  ’comparejtem’ 

’compaie_ilem’  -  "ARMY" 

’relop’  -  equal  to  an  array  of  characters 
’header_item’  -  Keyword 
4  character  in  the  ’compare_item’ 

’comparejtem’  -  "NAVY" 

’logop*  -  or 

’relop’  -  greater  than  a  multibyte  unsigned  int^er 
’header Jtem’  -  Upload  Time 
4  byte  ’comparejtem’  -  last  login  time 
’logop’  •  and 

(This  command  requests  all  files  which  were 
uploaded  after  the  user’s  last  login  time  and 
which  also  have  either  "ARMY"  or  "NAVY"  as 
a  keyword.) 


TABLE  6^Q  EXAMPLE  OF  A  select_resp  PACKET 


00000010 


2  byte  info  field 


10001  muinnnim  nnruinnnn 


Interpretation 


Number  of  files  placed  in  select  list 


L.  THE  INOLriE  COMMAND  AND  DELETE  RESPONSE  PACKETS 


The  qiedflcitfiofi  for  FTLO  does  not  allow  for  a  uan’-requested  file  deletion.  It 
assumes  diat  files  will  simidy  remain  aboard  die  satellite  until  thdr  expiration  dates  are 
exceeded,  m  until  die  satellite  itself  or  die  ground  controllers  cause  die  files  to  be 
deteted.  This  deljcmd,  dierefore,  has  no  equivalent  in  FTLO. 

The  information  field  of  the  deljand  contains  only  the  4-byte  file  number  of  the 
file  to  be  deleted.  The  satellite  reqxinds  to  a  deljmd  with  a  del_resp  packet.  The 
inf<»Tnation  field  of  this  packet  merely  cmitains  one  of  the  one-byte  error  codes  of  Table 
6.3D. 


1  TABLE  6  JD  ERROR  CODES  | 

BH  Pattern 

Error  Code 

nojerror 

00000100 

erjwjuch JHejutmber 

10010000 

er jtermssionjiemed 

If  the  satellite  indicates  nojerror  in  die  deljrtsp,  then  the  file  has  been  successfully 
deleted.  A  user  may  only  delete  files  uploaded  by  him  or  addressed  to  him  as  the  sole 
destinaticMi.  The  sat  oisures  these  criteria  are  met  by  inspecting  the  appropriate 
fields  in  the  file’s  hea>'vi  before  any  deletion  is  carried  out.  An  attempt  to  delete  any 
otho^  file  will  result  in  er jfermssionjiemed. 
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Vn.  PACKET  TSANSIllt  MODULE  -  STATE  TRANSmONS 


A.  TRIGGERS 

Tile  opetatkm  of  the  packet  transfo' module  is  based  iqwn  state  transitioiis  triggoed 
by  Ae  receipt  of  packets  from  die  user  and  messages  ftom  otho*  flight  software  modules. 
When  tte  user  on  die  ground  sends  a  cmd  packet  to  the  satellite,  die  leq^se  will 
dqpend,  in  part,  on  what  state  the  packet  transfer  module  is  in. 

The  architecture  of  the  packet  transfer  state  machine  can  easily  be  seen  in  the 
Estelle  qiecification  of  Appoidix  A.  The  trans  section  of  the  module  definition  clearly 
shows  all  possible  trantititms  from  one  state  to  another,  along  with  what  pack^  or 
message  triggers*  each  transition,  and  what  actirm  is  taken  as  a  result.  This  textual 
description  can  be  translated  into  a  more  visual  format  by  means  of  state  transition 
grqihs,  such  as  those  included  with  the  data  flow  diagrams  of  Appendix  B. 

B.  INSTANTIATIONS 

It  is  intended  that  multiple  users  should  have  access  to  the  mail  box  onboard  the 
satellite  "simultaneously".  This  is  achievable  because  all  user  transmissions  to  the 
satdlite  are  packetized.  BAX,  the  AX.2S  data  transfer  level  software,  can  administo’  up 
to  30  user  links  at  once.  As  each  AX.2S  frame  is  received,  BAX  determines  which  user 
it  is  from,  and  deals  with  it  according  to  the  AX.2S  protocol  and  the  state  of  the  link 
with  that  particular  uso:. 
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In  Older  for  the  packet  transfer  level  to  also  be  administered  many 
"simultaneous"  users,  there  must  be  a  copy  of  the  packet  transfer  module  associated  with 
endi  virtual  link.  The  fiict  diat  multiple  cofnes  of  the  packet  transfer  module  are 
initialized  can  be  seen  in  die  modvar  section  at  the  end  of  the  Estelle  software 
specification.  This  says  that  one  packet  transfer  module  is  created  for  each  link.  The 
definition  of  "Link_Type",  near  the  b^inning  of  the  qiecification,  indicates  that  there 
are  between  0  and  30  links.  When  a  packet  ti;&nsfer  module  receives  messages  from,  or 
sends  messages  to,  anmher  software  module,  the  qiecific  instantiation  involved  is 
indicated  by  the  initialization  param^er  ’link*.  The  packet  transfer  modules,  as  well  as 
the  channels  associated  with  them,  are  referaiced  as  array  elements;  the  ’link’  each  is 
associated  with  acts  as  the  array  index.  For  instance,  in  the  module  header  definition  of 
the  MAILBOX_CONTROL_TYPE,  it  is  stated  that  this  module  has  an  array  of  30 
(maxUnks)  Mailbox_Access_Channels.  In  the  modvar  section,  each  of  these  channels 
is  connected  to  a  different  copy  of  the  packet  transfer  module. 

C.  TRANSITIONS 

The  state  transitions  for  a  particular  instantiation  of  the  packet  transfer  module  are 
affected  only  by  packets  from  the  user  associated  with  the  link  being  administered  by  that 
module.  The  data  transfer  module,  as  explained  in  Ch^ter  V,  must  assemble  complete 
pack^  from  the  frame  data  seat  to  it  by  BAX.  Each  packet  is  sent  to  the  appropriate 
packet  transfer  module,  depending  upon  which  BAX  link  it  was  received  on.  Likewise, 
as  the  packet  transfer  modules  send  resp  packets  to  the  data  transfer  module  for 
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tnniaiwioii  via  BAX,  the  data  transfer  mocfele  must  break  eadi  packet  \q>  into  frames 
and  lend  them  via  the  iqifnoimate  BAX  link  to  teadi  the  intended  rec^ient. 

WhUeapackettransfer  module  is  in  any  particular  Mate,  only  certain  packets  feom 
die  user  wiU  have  meaning.  An  unexpected  packet  will  cause  any  actions  in  progress 
(sudi  as  iqdoading  or  downloading  a  file)  to  be  aborted.  Fl'LO  defines  unexpected  or 
inccmect  packets  as  suffident  cause  to  terminate  the  link  with  a  usm*.  The  ^ledficatitm 
in  Appendix  A,  however,  only  calls  for  the  packet  transfer  module  to  return  to  a  waiting 
state  after  abandoning  any  action  in  progress.  At  this  point,  the  module  is  ready  to 
accept  any  valid  command  from  the  user.  The  user  will  be  informed  of  the  problem  via 
an  a^iprc^riate  error jresp  packet.  After  receipt  of  any  error  message,  the  user  should 
assume  that  the  satellite  is  waiting  for  the  ground  station  to  initiate  a  new  action. 

D.  STATES 

FTLO  was  designed  primarily  for  use  with  satellites  with  full  duplex  c^iabilities. 
For  this  reason,  it  maintains  two  separate  state  machines,  one  for  the  uplink  process  and 
the  second  for  the  downlink  process.  PANSAT  is  a  half-duplex  communications  satellite. 
The  two  state  machines  of  FTLO  have  been  combined  into  a  single  machine  in  the 
q)ecification  of  the  PANSAT  packet  transfer  module.  The  states  are  listed  in  Table  7. 1 . 
Explanations  are  included  in  the  following  subsections. 


64 


1  TABLE  7.1  PACKET  TRANSFER  STATES  | 

1  Ex|riaiuition  of  State 

1  UUDL.UNINTT 

Ufdoad/Download  Uninitiated 

Waiting  f<v  an  Uj^kiad  or  Download  Command 

WATT.MAILBOX 

Waiting  for  a  Message  from  the  Mailbox  Control  Module 

UL_DATA_RX 

Ready  to  Uplink  Data 

UL_ABORT 

Upload  Aborted 

DL_FILE_DATA 

Downloading  a  File 

1.  UL/DL_UNINIT 

UL/DL_UNINrr  is  the  state  into  which  the  packet  transfer  module  is  first 
initialized,  before  a  user  link  has  been  established  with  it.  In  this  state,  the  module  does 
nothing  but  wait  to  be  assigned  a  user.  Upon  receipt  of  the  ’connection’  message  from 
the  data  transfer  module,  the  packet  transfer  module  asks  the  mailbox  control  module 
whether  or  not  the  new  user  has  an  active  selection  list,  and  moves  into  the 
WArr_MAILBOX  state  to  await  a  reply.  When  the  rq>ly  message  is  received,  the 
nuxlule  will  enter  the  UL/DL_CMD_WAn'  state.  The  packet  transfer  module  returns 
to  the  UL/DL_UNINIT  state  when  it  is  sent  a  ’disconnect’  message  by  the  data  transfer 
module,  r^ardless  of  what  state  it  is  in  when  this  message  is  received. 
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1  TABLE  7,2  STATE  TRANSITIONS  FROM  ULa)L_UNlNIT  | 

Reeeivcd 

htaage 

Actkm 

Next  State 

connection 

active_sl_req  message 

(Asks  the  mailbox  control  module  if  there  is 
an  active  sdectkm  list  for  this  user.) 

WAIT_MAILBOX 

2.  UL/DL_CMD_WAIT 

In  the  UL/DL_CMD_WAIT  state,  the  packet  transfer  module  is  waiting  for 
a  packet  from  the  user  which  will  initiate  either  an  upload  process  or  a  download 
process.  Packets  which  can  be  legally  received  while  in  this  state  are  listed  in  Table  7.3, 
along  with  the  resultant  actions  and  transitions.  Any  other,  unexpected,  packets  will 
result  in  an  uljsrrorjtsp  packet  with  the  error  code  erjll Jormedjmd,  and  the  module 
wiU  remain  in  the  state  UL/DL_CMD_WAIT. 


1  TABLE  7.3  STATE  TRANSITIONS  FROM  UIVDL_CMD_WAIT  | 

Received  Facket 
or  Message 

Action 

Next  State 

uploadjynd 

mail_num_req  message 
(Request  a  new  flle  number  or  a 
current  file  offset  from  the  mailbox 
control  module.) 

WAIT_MAILBOX 

deljcmd 

mail_del_req  message 
(Request  that  the  mailbox  control 
module  delete  a  file.) 

WAIT_MAILB0X 

selectjand 

mselect_req  message 

(Request  the  mailbox  control  module 

form  a  selection  list.) 

WAIT_MAILBOX  | 
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1  TABLETS  ST  ATE  TRANSITIONS  FROM  UL/I 

>L_CMD_WAIT 

Received  PKkcC 
erMemige 

Action 

Next  State 

dirjhortjmd 

dirjongjmd 

dir_req  message 

(R^uest  directory  information  from 
the  mailbox  control  module.) 

\IT_MAILBOX 

download_cmd 

mail_req  message 

(Request  file  data  from  mailbox 

control  module.) 

DL_FILE_DATA 

none 

UL/DL_CMD_WAIT 

disconnect 

none 

UL/DL_UNINIT 

other  packets 

ul_error_resp  packet 

UL/DL_CMD_WArr 

3.  WAIT_MAILBOX 

As  can  be  seen  in  Table  7.3,  most  packets  received  while  in  the 
UL/DL_CMD_WAIT  state  result  in  a  transition  to  the  WAIT_MAILBOX  state,  with  no 
immediate  response  packet  to  the  user.  Hiis  is  because  the  packet  transfer  module 
requires  information  from  the  mailbox  control  module  before  it  can  make  a  proper  reply 
to  the  user.  The  mailbox  control  module  analyzes  each  information  request  message  and 
rq)lies  with  an  sq)propriate  response  message.  The  response  of  the  mailbox  control 
module  will  determine  which  state  the  packet  transfer  module  will  enter  when  it  leaves 
the  WAIT_MAILBOX  state,  as  well  as  what  packet  it  sends  to  the  user.  The 
WArr_MAILBOX  state  may  also  be  entered  from  the  UL/DL_UNINIT  state  as  shown 
above,  or  the  UL_DATA_RX  state,  as  will  be  explained  below.  Table  7.4  summarizes 
the  mailbox  access  channel  messages  just  prior  to  a  transition  to  the  WAn'_MAILBOX 
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stite,  Uie  possible  rqdy  messages  from  the  mailbox  control  module,  and  the  resulting 
further  actions  and  state  transitions  of  the  packet  transfer  module.  No  user  command 
packets  are  expected  while  in  the  WAIT_MAILBOX  state,  as  the  user  should  still  be 
waiting  for  a  rq>ly  from  the  last  packet  sent  to  the  satellite. 


1  TABLE  7.4  STATE  TRANSITIONS  FROM  WAIT_MAILBOX  | 

Message 

I  Reply  Message 

1  Action 

1  Next  State 

active_sl_req 

active_sl_resp 

logm_resp 

pack^ 

UL/DL  CMD 
WAIT  “ 

mail_num_req 

mail_num_resp, 
no  errors 

ul_goj"esp 

packet 

UL_DATA_RX 

mail_num_resp, 

error 

ul_error_resp 

packet 

UL/DL  CMD 
WAIT  ~ 

mail^recv 

mail_recv_resp, 
no  errors 

Change  current 
upload  offset 

UL_DATA_RX 

mail_recv_resp, 

error 

ul_nak_resp 

packet 

UL_ABORT 

mail_close_req 

mail_close_resp, 
no  errors 

ul_ack_resp 

packet 

UL/DL  CMD 
WATT  ” 

mail_close_resp, 

error 

ul_nak_resp 

packet 

UL_ABORT  1 

mail_del_req 

mail_del_resp 

del_resp  packet 

UL/DL  CMD  1 
WAIT 

mselect_req 

mselect_resp,  no 
errors 

selectjresp 

packel 

UL/DL  CMD 
WAIT  “ 

mselect_resp, 

error 

dl_€rror_resp 

packet 

UL/DL  CMD 
WAIT  ~  1 
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1  TABLE  7.4  STATE  TRANSITIONS  FROM  WAlT_MAILBOX  | 

Message 

Reply  Message 

Action 

Next  State 

dir_req 

directory,  no 
errors 

data  pa..ket, 
data_end  packet 

UL/DL  CMD 
WAIT  “ 

directory,  error 

dl_error_resp 

packet 

UL/DL  CMD 
WAFT  “ 

disctmnect 

UL/DL 

UNINlf 

4.  UL_DATA_RX 

The  packet  transfer  module  enters  the  UL_DATA_RX  state  after  the  user  has 
sent  an  uploadjand  and  the  mailbox  control  module  has  replied  to  the  resulting  inquiry 
with  the  2q)propriate  flle  number  or  offset.  That  is,  this  state  is  first  entered  from  the 
WAIT_MAILBOX  state.  When  the  module  is  in  the  UL__DATA_RX  state,  it  is  ready 
to  receive  data  packets  from  the  user.  As  each  packet  it  received,  the  packet  transfer 
module  passes  the  file  data  on  to  the  mailbox  control  module  for  storage,  entering  the 
WArr_MAILBOX  state  each  time  to  await  acknowledgement.  When  the  data_end 
packet  is  received,  the  packet  transfer  module  requests  that  the  mailbox  control  module 
close  the  Ble  and  conduct  integrity  checks  on  it.  The  result  of  these  checks  will 
determine  whether  the  packet  transfer  module  returns  directly  to  the 
UL/DL_CMD_WAIT  state,  or  goes  into  the  UL_ABORT  state,  as  indicated  in  Table  7.4. 
The  state  transitions  out  of  UL_DATA_RX  are  summarized  in  Table  7.5.  The  only  legal 
user  packets  which  can  be  received  while  in  this  state  are  data  and  data _end.  If  the 
packet  transfer  module  receives  an  unexpected  packet  while  in  this  state,  it  will  send  a 
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’iiiail_cloK_req'  to  tiie  maittwx  cootnd  module,  an  uljirrorjt^  packet  to  the  uaer,  and 


then  fetum  to  die  UL/DL_CMD_WArr  state.  If  the  uso’  beotMues  disconnerted  u^iile 
die  module  is  in  the  UL_DATA_RX  state,  it  will  send  a  *mail_close_req’  message  to  the 
mailbox  control  module  and  then  rrtum  to  the  UL/DLJJNlsrr  state. 


1  TABLE  7.5  STATE  TRANSITIONS  FROM  17L_DATA_RX  | 

Recdved  Placket  <»* 
Messa^ 

Message  Sent 

Next  State 

date 

mailjrecv 

WAIT_MAILBOX 

datajtnd 

mail_close_req 

WAIT_MAILBOX 

other  packets 

mail_close_req, 
idjtrrorjtsp  Packet 

UL/DL_CMD_WAIT 

disconnect 

mail_close_req 

UUDL_UNINIT 

5.  UL_ABORT 

The  UL_ABORT  state  is  entered  whenever  a  problem  is  found  with  an 
ongoing  upload  prior  to  receipt  of  the  data_end  packet.  While  the  packet  transfer 
module  is  in  the  UL_ABORT  state,  all  d<aa  packets  are  discarded.  It  will  remain  in  this 
state  until  a  datajend  packet  is  received,  an  unexpected  packet  is  received,  or  the  user 
is  disconnected.  The  state  transitions  out  of  UL_ABORT  are  summarized  by  Table  7.6. 
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TABLE  7.6  STATE  TRANSITIONS  FROM  UL  ABORT 


Received  nickcC  or 
Meanfe 

FhckctSeiit 

Next  State 

data 

ntme 

UL_ABORT 

datajend 

none 

UL/DL_CMD_WAIT 

other  packets 

ul_error_resp 

UL/DL_CMD_WAIT 

diaconnect 

UL/DL_UNINIT 

6.  DL_F1LE_DATA 

The  state  DL_FILE_DATA  is  altered  from  the  IJL/DL_CMD_WAIT  state 
whenever  a  properly  formatted  dowrUoadjynd  is  received  from  the  user.  If  a  badly 
formatted  downloadjcmd  is  received,  the  user  will  be  sent  a  dl_error_resp  and  the  packet 
transfer  module  will  remain  in  the  UL/DL_CMD_WAIT  state. 

Just  prior  to  entering  the  DL_FILE_DATA  state,  the  packet  transfer  module 
soids  a  ’mail_req’  message  to  the  mailbox  control  module.  While  in  the 
DL_FILE_DATA  state,  the  packet  transfer  module  simply  waits  for  ’mail_resp’  messages 
from  the  mailbox  module  containing  file  data  to  be  transmitted  to  the  user.  As  each 
inece  of  the  file  arrives,  it  is  sent  on  to  the  user  in  a  data  packet.  When  the  mailbox 
(xmtrol  module  indicates  that  the  last  byte  of  the  file  has  been  provided,  a  datajend 
packet  is  sent  to  the  user.  The  packet  transfer  module  remains  in  the  DL_FILE_DATA 
state  until  either  a  dl_ack_cmd  or  a  dl_nak_cmd  is  received  from  the  ground.  Then  it 
returns  to  the  UL/DL_CMD_WAIT  state.  The  satellite  takes  no  particular  action  upon 
recdpt  of  a  dljutkjcmd.  It  will  be  the  reqxmsibility  of  the  ground  station  to  request  a 
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MW  dowBlotd  of  the  lame  fik  itt  a  futon  tune  if  the  uier  10  denies.  If  the  file  number 


nquened  fiw download  does  not  exist,  aLdl_enorje^  packet  will  be  tnnnnitted  and  the 
module  will  mtum  immediatdy  to  die  UL/DL_CMD_WA1T  state.  The  state  transitions 
from  DL_F1LE_DATA  an  shown  in  Table  7.7. 


1  TABLET.?  STATE  TRANSITIONS  FHOM  DL.nLE^^DATA  | 

Reednd  Measafe  OT 
Packet 

Packet  Salt 

NextSUte 

mail_re^,  error 

dljsrrorjesp 

UL/DL_CMD_WAIT 

niai2_n^,  no  error 

data 

DL_FILE_DATA 

mail_nsp,  end  of  file 

datajmd 

DL_FILE_DATA 

dljockjcmd 

dljcompletedjrsp 
dl_ack  message 

UL/DL_CMD_WAIT 

dljtakjmd 

dljobortedjvsp 

UL/DL_CMD_WAIT 

other  Packets 

dljtrrorjresp 

UUDL_CMD_WAIT 

discrmnect 

UL/DL_UNINIT 
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VHL  MAILBOX  CX>NTROL  MODULE 


A.  FUNCTION 

The  primary  nde  of  die  MAILBOX_CONTROL  module  is  to  keep  track  of  the 
mail  files  whidi  have  been  iqdoaded  to  PANSAT  from  users  on  the  ground.  It  also 
keeps  trade  of  usm’-aooessible  telemetry  files  which  have  been  jffqnted  by  the 
TBLEMETRY_GATHER  module  for  downloading  to  interested  users,  and  "bulletins" 
which  have  been  posted  by  die  ground  control  station  for  the  informatiem  of  all  PANSAT 
clients.  The  users'  active  selection  lists  are  also  maintaiimd  by  the  mailbox  control 
module. 

The  mailbox  control  module  has  only  one  state,  WAIT.  This  state  name 
exemplifies  the  method  employed  by  the  module  to  carry  out  its  duties.  It  "waits"  until 
it  leodves  a  request  for  information  or  a  psu:ket  of  file  data  from  the  pactet  transfer 
module,  or  is  ndified  of  a  file  posted  by  the  telemetry  module  or  by  the  ground  control 
module.  Most  housdoeqiing  functions  within  the  "mailbox”  are  triggered  by  receipt  of 
these  messages.  The  mailbox  control  module  responds  to  the  received  message,  carries 
out  any  necessary  activity,  and  then  continues  wuting  until  the  next  message  arrives. 
A  few  administrative  functions,  such  as  purging  all  mail,  must  be  directed  by  special 
ctmimand  messages  from  the  ground  control  or  auto  control  modules. 
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B.  SOimCESECOKDS 


The  inediod  ein[doyed  by  tiie  mailbox  centred  module  to  keep  track  of  all  ujdoaded 
files  and  all  users’  active  sdection  lists  is  a  linked  list  of  Souice_Reo(nds.  The 
Souice_Reo(»d  type  is  a  data  structure  which  contains  inf<»mation  which  links  every 
sternd  file  with  the  source  from  which  it  was  originally  uploaded,  as  well  as  an  active 
selection  list  for  any  source  (ustf)  that  has  requested  one.  The  fields  of  the 
Source_Record  are  listed  in  Table  8.1,  along  with  the  fimetion  of  each  field. 


1  TABLE  8.1  FIELDS  OF  THE  SOURCE  RECORD  | 

Field 

Type 

function 

source_num 

uint 

Contains  a  unique  int^er  assigned  to  each 
ground  user  who  has  uploaded  any  files 
currently  stored  onboard  the  satelUte  or  has  an 
active  sdection  list.  Used  as  the  first  2  bytes  in 
the  file  numbers  assigned  to  each  file  uploaded 
by  this  user. 

call 

Callsign^Type 

Hie  call  sign  belonging  to  the  client  assigned 
the  above  *source_num’.  The  call  sign  will  be 
used  as  the  DOS  file  name  for  all  files  uploaded 
by  this  clioit.  Each  file  will  be  assigned  an 
extension  from  "001"  to  "999". 

selected 

Select_List 

The  Sdect_List  structure  includes  the  fields 
’num_ser,  a  uint  indicating  the  number  of  files 
in  the  client’s  selection  list,  and  ’sel’,  a 
variable  loigth  array  of  the  mail  numbers  of 
those  files.  ’num_ser  must  be  <  =  maxjnail, 
the  maximum  number  of  files  allowed  in  one 
selection  list.  A  ’num_sdl’  equal  to  ’0’  indicates 
"no  active  selection  list". 
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TABLE  8.1 


SOURCE  RECORD 


Field 

ll^pe 

1  Function 

iiext_iiiail 

uint 

The  index  into  the  ’sel*  array  which  marks  the 
*next*  mail  file  in  the  selection  list  not  yet 
downloaded  by  the  client.  When  *n«(t_mair 
becomes  >  =  ’num_ser,  the  selection  Ust  is 
"empty”  if  another  request  to  download  the 
"next"  file  arrives. 

next_dir 

uint 

The  index  into  the  ’sel’  array  which  marks  the 
"next"  mail  file  in  the  selection  list  for  which  a 
directory  entry  has  not  yet  been  downloaded  by 
the  clirat.  When  ’next_dir’  becomes  >  = 
’num_ser,  the  selection  list  is  "empty"  if 
another  request  to  download  directories  for  the 
"next"  10  files  arrives.  When  both  ’next_mair 
and  *next_dir’  are  >=  ’num_ser,  ’num_ser 
reverts  to  *0*  and  the  client  no  longer  has  an 
active  selection  list. 

next_cxt 

File  Ext  = 
000”999 

The  next  file  extension  to  be  used  on  a  file 
uploaded  by  this  client.  In  binary  form,  the 
*ext*  is  used  as  the  last  2  bytes  in  the  file 
number  assigned  to  the  file.  In  ascii  form,  it 
forms  the  3  character  DOS  file  extension. 

num_act 

uchar 

The  number  of  files  uploaded  by  this  client 
which  are  still  being  stored  aboard  the  satellite. 

next_num 

‘^Source_Record 
(pointer  to 
Source_Record) 

Pointer  to  the  next  Source_Record,  numerically 
by  ’source_num’. 

next_call 

‘*‘Source_Record 

Pointer  to  the  next  Source_Record, 
alphabetically  by  ’call’. 
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C.  RESPONSE  TO  MESSAGES  FROM  THE  PACKET  TRANSFER  MODULE 


&r  the  greatest  number  of  messages  received  by  the  mailbox  contrd  module 
originate  from  the  packtt  transfer  module,  via  the  Mailbox_Access  Channel.  CluqHer 
Vn  lists  many  transitions  of  the  packet  transfo’  module  to  the  WATT^MAILBOX  state. 
These  oansitions  indicate  that  the  packet  transfer  module  has  requested  information  from 
die  mailbox  control  module  and  is  awaiting  a  rqily.  The  packet  transfer  module  also 
soids  messages  to  the  mailbox  control  module  while  remaining  in  the  UL_DATA_RX 
state.  The  activities  of  the  mailbox  control  module  triggered  by  each  message  type  from 
the  packet  transfer  module,  and  the  required  reply  messages,  are  addressed  in  the 
following  subsections. 

1.  The  *active_sl_req*  and  *active_sl_resp*  Messages 

When  the  packet  transfer  module  sends  an  ’active_sl_req'  message,  it  is 
inquiring  whether  there  is  an  active  selection  list  for  a  particular  user.  The  mailbox 
control  module  must  check  the  source  records  to  see  if  the  user  has  an  active  selection 
list  or  not.  An  ’active_sl_resp’  message  is  returned  to  the  packet  module,  indicating  true 
if  the  user  does  have  an  active  list,  and  false  otherwise. 

2.  The  *niail_num_req’  and  ’nuil_num_resp*  Messages 

A  ’mail_num_req’  message  indicates  that  a  user  wants  to  upload  a  file.  If 
this  is  a  new  file,  a  file  number  is  required  for  it.  If  it  is  an  upload  continuation,  the 
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cuimU  file  oltec  is  needed.  The  mailbox  module  must  entire  that  there  is  enough  room 
in  memory  to  store  a  file  the  length  indicated  in  the  message.  If  the  indicated  fik 
mimber  is  *0x00000000',  the  mailbox  will  get  the  user’s  source  number  and  next 
exiensioo  fiom  die  source  records  (cv  assign  a  new  source  number  if  necessary)  and  ftrnn 
a  new  file  number.  If  the  file  number  in  the  *mail_num_req*  message  is  not 
*0x00000000’,  die  mailbox  module  wUl  find  the  current  length  of  it’s  partial  copy  of  the 
file,  fii  the  *mail_num_resp*  message,  the  mailbox  module  will  supply  the  pack^  module 
widi  the  required  file  number  or  offset  for  the  upload,  or  indicate  that  an  error  has 
occurred  (such  as  insufficient  space  or  incorrect  file  number). 

3.  The  *iiiail_rec¥*  and  *iiiaii_recv_resp*  Messages 

The  *mail_recv’  message  passes  file  data  which  has  been  received  from  a  user 
to  the  mailbox  module.  The  data  must  be  appoided  to  the  appropriate  file.  The  mailbox 
module  attempts  to  find  and  qpen  the  file  to  which  the  data  belongs  and  sqipend  it.  The 
*mail_recv_iesp*  will  indicate  whether  the  data  has  been  stored  successfully  or  whether 
an  error  has  occurred. 

4.  Hie  *iiiail_close_req*  and  ’nuiil_close_resp*  Messages 

The  ’mail_close_req’  message  can  indicate  one  of  two  situations.  Either  a 
data^end  packet  has  arrived,  indicating  that  an  upload  has  been  completed,  or  an  upload 
has  been  interrupted  due  to  user  disconnect  or  an  unexpected  packet.  If  an  upload  has 
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twn  oomplelBd,  die  pecfcet  module  will  indicete  diis  by  aettiog  the  ’ieq_xe9*  panuneler 
of  die  message  to  true,  requesting  a  response.  In  diis  case,  the  mailbox  module  will 
check  die  intc^ty  of  the  uploaded  file  and  repmt  the  results  in  the  ’mail_close_re^’ 
message.  If  ’req_resp'  is  set  to  false,  the  upload  has  been  interrupted  and  the  mailbox 
module  will  simply  close  the  die  and  wait  for  the  upload  to  be  continued  at  a  later  time. 

5.  Hie  *iiisdcct_req*  and  *nisdect_reiq>*  Messages 

An  *mselect_req*  message  forwards  to  the  mailbox  module  the 
Select_Structure  of  a  client  requesting  to  form  a  new  active  selection  list.  The  mailbox 
module  must  parse  the  Select_Structure  and  either  prepaid  the  default  selecticm  list  or 
evaluate  the  selection  equation  with  respect  to  each  file  in  the  mail  box.  The  file  number 
of  each  matching  (or  default)  file  will  be  placed  in  the  clirat’s  selection  list.  There  is 
a  maximum  number  of  file  numbers  which  can  be  placed  in  any  selection  list.  When  this 
number  is  reached,  further  selection  will  be  discontinued.  The  ’mselect_resp’  message 
indicates  how  many  dies  have  been  placed  in  the  selection  list,  or  if  an  error  has 
occurred.  Any  prior  existing  list  will  be  discarded. 

6.  The  *iiiail_req’  and  ’niail_resp*  Messages 

The  packet  transfer  module  sends  a  ’mail_req’  message  in  order  to  obtain  die 
data  for  download  to  a  client.  A  die  number  and  offset  will  be  included  in  the  message. 
If  the  *next”  die  in  the  selection  list  is  requested,  the  indicated  die  number  will  be 
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*0x00000000',  and  the  mailbox  module  must  consult  the  clioit’s  source  record  to 
determine  die  actual  file  number  of  the  next  file  in  the  list.  The  offset  for  the  "next*  file 
will  always  be  zero.  When  the  next  data  s^  from  that  file  is  requested,  the  file  number 
and  q^nopriate  non-zero  offset  will  be  known,  and  included  in  the  *mail_req*  message. 
The  mailbox  module  will  b^in  at  the  sqipropriate  file  offset  and  b^in  copying  bytes  into 
the  data  buffer.  It  will  copy  either  the  number  of  bytes  which  will  fit  into  one  packet, 
fx  the  remaining  bytes  in  the  file,  whichever  is  less.  Hther  the  data  buffer  or  an  error 
indication  will  be  sent  back  to  the  packet  module  in  the  ’mail_resp’  message.  Whra  the 
end  of  a  file  has  been  sent  to  the  packet  module,  the  mailbox  module  responds  to  the  next 
’mail_req’  with  an  empty  data  buffer  and  no  error  code.  This  indicates  to  the  packet 
buffer  that  it  is  time  to  said  the  datajend  packet. 

7.  The  *dl_ack’  Message 

The  packet  transfer  module  will  send  a  ’dl_ack’  message  to  the  mailbox 
control  module  after  receiving  a  dl_ack_cmd  packet  fi-om  the  user.  Only  if  a  ’dl_ack’ 
imssage  is  received  will  the  mailbox  module  change  the  *next_mair  field  in  the  user’s 
source  record.  The  ’next_mail’  pointer  is  only  advanced  after  the  file  'ndicates  has 
been  successfully  downloaded  to  the  client.  The  number  of  the  file  acknowledged  will 
be  included  in  the  ’dl_ack’  message  along  with  the  client’s  call  sign.  The  file  number 
must  match  that  indicated  by  the  ’next_mair  field  of  the  client’s  source  record  for  the 
field  to  be  updated. 
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8.  The  *^_req'  mid  'direetmry* 

The  *dir_req*  message  lequests  directed  informatiem  for  dther  the  file 
number  indicated,  or  the  "next"  ten  files  in  the  client’s  active  selection  list.  Directory 
information  for  a  file  is  simply  a  ct^y  of  the  PANSAT  file  header.  If  a  file  number  is 
indicated,  the  mailbox  module  places  a  copy  of  the  appre^riate  header  in  the  data  buffer 
which  is  send  back  with  the  ’directory*  message.  If  the  "next"  10  entries  are  requested, 
the  mailbox  module  consults  the  source  record  to  determine  whether  there  is  an  active 
list,  and  if  so,  which  is  the  "next"  file  for  which  a  directory  entry  has  not  yet  been  sent. 
The  headers  are  copied  for  the  next  10  files  on  the  list,  beginning  with  the  one  nuurked 
by  ’next_dir’.  If  there  are  less  than  10  remudning  on  the  list,  they  are  all  sent.  There 
is  no  downl^  acknowledge  associated  with  directories,  and  the  ’next_dir’  counter  is 
automatically  advanced  when  the  ’directory’  message  is  sent  back  to  the  packet  transfer 
module. 

9.  The  ’niail_del_req*  and  ’nuiil_del_resp’  Messages 

The  packet  transfer  module  sends  a  ’mail_del_req’  when  a  user  wishes  to 
delete  a  file  from  the  satellite’s  mailbox.  The  mailbox  module  must  first  ensure  that  the 
user  in  question  is  authorized  to  delete  the  indicated  file.  A  user  may  only  delete  a  file 
which  they  have  uploaded,  or  one  which  is  addressed  to  them  as  the  sole  recipient.  The 
mailbox  module  knows  who  uploaded  the  file,  since  the  file  name  is  the  same  as  the 
source  call  sign.  It  can  consult  the  destination  fields  of  the  file  header  to  determine 
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whelhar  Ac  requesting  user  is  the  sole  leciprent.  If  the  is  authorized,  it  will  be 

carried  out,  and  a  no_error  indicatitm  rdurned  to  the  packet  module  in  the 
'nuul_del_reap’  message.  Otherwise,  the  er  j>ermission_demed  code  will  be  returned. 

D.  RESPONSE  TO  MESSAGES  FROM  OTHER  MODULES 

The  mailbox  ctxitrol  module  may  also  be  tasked  to  respond  to  messages  from 
modules  other  than  the  packet  transfer  module.  These  messages  may  come  via  one  of 
the  Mailbox_Admin_Channels  or  via  the  Telemetry_Storage_Channel.  The  latter  channel 
is  connected  to  the  TELEMETRY_GATHER  module,  while  one  copy  of  the  former  is 
connected  to  the  AUTO_CONTROL  module  and  another  is  connected  to  the 
GROUND_CONTROL  module.  None  of  these  three  modules  has  been  completely 
^)ecified,  and  the  requirements  for  them  are  still  evolving.  Some  possible  functions  for 
them  have  been  suggested,  and  those  which  impact  upon  the  mailbox  control  module  will 
be  discussed  in  the  following  subsections. 

1.  The  ’llst_inail’  and  ’niail_Ust’  Messages 

The  NPS  ground  control  station  personnel  retain  the  right  to  inspect  all 
messages  in  the  mailbox,  regardless  of  the  upload  sources  or  the  addressees.  The  ground 
control  station,  when  it  is  so  desired,  can  request  a  list  of  all  files  currently  maintained 
in  the  memory,  or  a  partial  list  of  only  those  files  "from"  or  "to”  a  particular  call  sign. 

This  command  is  received  by  the  GROUND_CONTROL  module,  which  responds  . 


81 


requesting  the  iq>propriate  file  list  from  the  mailbox  control  module  using  a  ’list^mail’ 
message.  The  mailbox  module  responds  with  a  ’mail_list’  message  which  indicates  the 
number  of  files  matching  the  criteria  of  the  *list_mair  message  and  provides  a  list  of  all 
of  die  ^^n^iriate  file  numbers.  From  this  list,  the  ground  control  module  or  the  ground 
control  station  persmmel  can  thoi  choose  files  to  download. 

2.  The  *post_bulletin*  and  *del^_bul]etin*  Messages 

The  ground  control  module  has  the  same  access  to  the  file  handling  facilities 
of  the  Space  Craft  Operating  System  as  does  the  mailbox  control  module.  For  this 
reason,  it  does  not  need  to  go  through  the  mailbox  module  in  order  to  "post”  a  bulletin, 
which  really  consists  only  of  storing  a  file  with  the  name  "BULLETIN.xxx”  in  the  mail 
storage  area.  (File  lists  such  as  those  discussed  in  the  previous  subsection  are  requested 
from  the  mailbox  module  merely  to  take  advantage  of  its  enhanced  association 
capabilities  using  the  source  records  it  maintains.)  The  mailbox  module  should, 
however,  maintain  a  complete  set  of  source  records,  including  one  for  the  ground  control 
station.  When  a  bulletin  is  posted,  the  ground  control  module  informs  the  mailbox 
module  using  a  ’post_bulletin’  message,  so  that  an  appropriate  file  number  can  be 
assigned  and  the  source  record  can  be  updated.  Similarly,  when  a  bulletin  is  deleted,  the 
mailbox  module  is  informed  by  a  ’deletejbulletin’  message. 
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3.  Ite  *ftiBjiiaiEMn*  and  *purgejDiail*  Measafes 

Whenever  a  user  requests  to  upload  a  file,  the  mailbox  module  must  first 
detennine  whether  there  is  room  for  it  in  the  memory.  If  it  finds  that  there  is  not  enough 
romn,  it  does  some  "house-cleaning”,  deleting  all  files  which  have  passed  their  expiration 
dates.  This  is  the  tmly  time  the  mailbox  module  deletes  files  on  its  own,  so  that  many 
files  may  actually  remain  onboard  the  satellite  for  longer  than  the  nominal  time  allowed. 
After  the  mailbox  module  has  deleted  all  fUes  which  have  expired,  it  once  again  checks 
to  see  if  there  is  enough  room  to  upload  the  new  file  as  requested  by  the  user.  If  there 
is  still  not  enough  room,  the  mailbox  module  must  deny  the  request  to  upload.  At  the 
same  time,  it  informs  the  AUTO_CONTROL  module  of  the  problem  with  a 
’full_mailbox’  message. 

Perhaps  in  response  to  a  ’full_mailbox’  message,  or  pertiaps  in  obedirace  to 
a  ground  station  command,  or  for  some  other  pressinr  reason,  the  ground  control  or  auto 
control  module  can  direct  the  mailbox  module  to  "purge"  the  mail  box.  The 
’puige_mail’  message  will  indicate  whether  all  mail  files  should  be  deleted,  or  all  flies 
posted  prior  to  some  designated  upload  time,  or  all  files  "from"  or  "to"  a  particular  call 
sign.  This  purge  is  done  via  the  mailbox  module,  so  that  it  will  have  the  chance  to 
update  all  affected  source  records. 
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4.  The  *store_iiser_tdein*  and  *dekte_iiser_telem*  Messages 

Like  the  ground  control  and  auto  control  modules,  the 
TELEMETRY_GATHER  module  also  has  complete  access  to  the  SCOS  file  management 
ctqnbilities.  When  user-accessible  telemetry  data  is  to  be  posted,  it  merely  saves  a  file 
called  "USRTELEM.xxx"  in  the  mail  storage  area.  These  telemetry  files  can  also  be 
delved  by  the  telemetry  module  when  they  become  outdated.  In  the  interest  of 
maintaining  a  complete  set  of  source  records,  the  mailbox  control  module  is  informed  of 
these  actions  via  the  *store_user_telem*  and  ’delete_user_telem’  messages. 
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K.  REMAINING  MODULES 


A.  TELEMETRY  GATHERING  MODULE 

In  the  cumnt  PANSAT  flight  software  ^)eciflcation,  14  sq)arate  software  modules 
have  been  defined  at  the  module  header  definition  level.  Of  these,  detailed  module  body 
definitions  have  been  develq)ed  for  4.  The  DATA_TRANSFER, 
PACKETJTRANSFER,  and  MAILBOXjCONTROL  modules  are  described  in  Chapters 
V  through  Vm  of  this  thesis.  A  preliminary  module  body  definition  for  the 
PASSWORD_CONTROL  module  has  bera  written,  but  will  not  be  released  to  the 
general  public.  Two  modules,  PRIMrnVE_AX2S  and  PRIMrnVE_SW_LOAD£R,  are 
actually  commercial  software  products,  BAX  and  PHTX.  The  capabilities  of  these 
programs  will  be  accessed  by  various  PANSAT  modules,  but  no  body  definitions  will  be 
written  for  them,  because  there  is  no  need  to  ^)ecify  existing  software,  only  the 
interfaces  to  it.  The  body  definitions  of  the  remaining  8  modules  will  be  highly 
dqiendant  upon  the  actual  hardware  configuration  of  the  satellite,  which  is  still 
undergdng  daily  design  changes.  Central  to  the  (^)eration  of  these  remaining  modules 
will  be  the  operation  of  the  TELEMETRY_GATHER  module. 

The  function  of  the  telonetry  gathoing  module  is  to  collect  data  on  the  operation 
of  die  satellite  from  which  control  dedsicms  can  be  made,  both  by  the  automatic  control 
module  (AUTO_CONTROL)  and  the  ground  ccmtrol  station  posonnel  at  NPS.  In  order 
to  obtain  mudi  of  this  data,  the  tdemetry  gadming  module  has  direct  amtrol  over  the 
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A/D_DRIVER  module  which  operates  the  analog-to-digital  converters  and  associated 
mult^texors  in  order  to  obtain  relevant  sensor  data,  such  as  btutny  voltages  or  solar 
array  temperatures.  CXher  telemetry  information  will  come  from  the  BAX  and  SCOS 
software,  which  maintain  various  stati^cs  about  the  communications  and  <^>erating 
environments. 

The  hardware  tdem^ry  points  which  have  been  defined  thus  far  are  listed  in  Table 
9.1.  The  best  situation  is  for  each  point  to  stay  within  the  expected  or  "nominal"  range. 
When  a  reading  goes  outside  the  nominal  range,  there  is  still  no  serious  system 
degradation  unless  it  also  goes  outside  the  "curating  range".  At  this  point,  there  may 
be  no  immediate  danger  to  the  system,  but  a  trnid  may  have  started  which  will  soon  lead 
to  (^laadonal  difficulties.  Whoi  a  reading  goes  outside  the  "red  alert"  range,  immediate 
correcticMiai  actions  must  be  initiated,  if  they  have  not  been  already.  System  failure 
could  be  imminent.  Many  of  the  exact  values  for  these  ranges  have  not  yet  been 
determined.  The  proper  pievoitive  and/or  correctional  steps  to  be  taken  in  each  situation 
are  also  still  under  study.  The  values  contained  in  Table  9.1  are  the  best  estimates 
available  at  this  time,  but  are  subject  to  change.  Those  readings  for  which  no  estimated 
values  have  yet  been  determined  are  marked  with  "tbd".  The  "totals"  listed  are  for  the 
srasors  controlled  by  one  Digital  Control  System  (DCS)  board,  on  which  will  be  running 
one  cc^y  of  the  flight  software.  The  current  design  calls  for  the  entire  DCS  to  be 
duplicated,  and  for  each  board  to  be  attached  to  its  own  complete  and  sq>arate  set  of 
sensors. 
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TABLE  9. 

.1  HARDWARE  1 

rELEMETRY  FOIN 

rrs 

Poiiit 

Nom 

Inal 

Operating 

Red  Aim  1 

Min. 

Max. 

Min. 

Max. 

Min. 

Max. 

Solar  Array 
Temperatures  (17  total) 

(yc 

50“  C 

-20“  C 

120“  C 

-30“  C 

140“  C 

Battery  Voltages 
(2  total) 

12  V 

13  V 

11.5  V 

13.5  V 

10  V 

15  V 

Batt^  Temperatures 
(4  total) 

-1.1“  C 

10“  C 

-6.7“  C 

26.7“  C 

-15“  C 

50“  C 

Battery  Discharge 
Currents  (2  total) 

tbd 

tbd 

tbd 

tbd 

tbd 

tbd 

Electrical  Power 

System  (EPS)  Bus 
Voltage  (1  tc^) 

tbd 

tbd 

tbd 

tbd 

tbd 

tbd 

EPS  Board 

Temperature  (2  total) 

0“C 

40“  C 

-10“  C 

50“  C 

tbd 

tbd 

Transmitter  Current 
(1  total) 

tbd 

tbd 

tbd 

tbd 

tbd 

tbd 

Transmitter  RF  Power 
(2  total) 

tbd 

tbd 

tbd 

tbd 

tbd 

tbd 

Transmitter 

Temperature  (2  total) 

0“C 

40“C 

-10“  C 

50“  C 

tbd 

tbd 

Received  Signal 

Straigth  (2  total) 

tbd 

tbd 

tbd 

tbd 

tbd 

tbd 

Receiver  Temperature 
(2  total) 

0“C 

40“  C 

-10“  C 

50“  C 

tbd 

tbd 

Srase  Relays  for  State 
of  Communications 
Hardware  (total  tbd) 

tbd 

tbd 

tbd 

tbd 

tbd 

tbd 

DCS  Board 

Temperature  (2  total) 

0“C 

40“C 

-10“  C 

50“  C 

tbd 

tbd 
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The  tdbmetry  gadwring  module  maintains  a  list  of  sensor  points  with  timing 
intoivals  and  expected  operating  ranges  for  each.  This  list  can  be  updated  by  commands 
from  the  ground  control  station,  which  can  cause  points  to  be  added  or  delved,  or  can 
change  the  timing  intervals  for  obtaining  readings  from  various  points.  Some  timing 
intervals  may  be  changed  dynamically  by  the  automatic  control  module  or  the  telemetry 
gathering  module  itself,  based  upon  trends  in  the  readings  or  upon  reading  which  are  out 
of  the  expected  ranges. 

Table  9.2  lists  some  "operating  environment  telemetry  points"  which  can  be 
gathered  by  SCOS,  and  passed  to  the  telemetry  gathering  module  for  inclusion  in  the 
telemetry  files.  Table  9.3  lists  some  "communications  environment  telemetry  points" 
which  can  be  gathered  by  BAX,  and  may  be  of  interest  to  the  ground  station  controllers. 
BAX  has  the  capability  to  maintain  a  fi^le  of  this  data  itself  and  to  download  it  directly 
to  the  ground  control  station.  Whetho*  the  information  will  be  passed  to  the  telemetry 
gathering  module  to  be  included  with  the  rest  of  the  telemetry,  or  whether  this  separate 
"BAX  telemetry"  file  will  be  maintained  and  passed  to  the  ground  control  station  as  the 
result  of  a  separate  ground  station  command,  has  not  yet  been  determined.  Table  9.4 
contains  a  list  of  other  general  system  data  which  may  be  collected  by  the  telemetry 
gathering  module  directly  foom  the  satellite  hardware  or  from  the  other  software 
modules.  In  some  cases,  such  as  the  data  points  listed  under  "LOGIN"  and 
"MAILBOX",  existing  module  specitications  will  have  to  be  modified  in  order  to  require 
the  software  to  gather  the  data  required  by  the  telemetry  module.  Such  moditications 
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will  be  pos^iKmed  until  it  has  been  decided  which  of  these  data  points  will  be  of  most 
mterest  to  the  ground  staticm  controllers,  and  what  sampling  intervals  will  be  required. 


1  TABLE  9  J  SCOS  TELEMETRY  POINTS  | 

Data  Point 

Data  Type 

1  Description _ I 

Scheduler  Events 

List  of  numbm 

Operating  System  multi-  I 
tasking  evoits  (tasks  1 

running  &  scheduled).  | 

Timer  Events 

List  of  numbers 

Operating  System  tasks  1 
in  queue.  | 

SCOS  Service  Calls 

List  of  numbers 

General  Operating  I 

System  information.  1 

1  TABLE  9.3  BAX  TELEMETRY  POINTS  | 

BAX  Data 

Point 

Data 

Type 

Description  I 

smallct 

uint 

Count  of  received  frames  containing  <  32  bits. 

nonint 

uint 

Count  of  received  frames  with  a  bit  Iragth  not  evenly 
divisible  by  8 

bigcnt 

uint 

Count  of  received  frames  that  exceed  maximum  size. 

abortcnt 

uint 

Count  of  received  frames  that  are  aborted. 

overcnt 

uint 

Count  of  receiver  overruns. 

crc 

uint 

Count  of  receiver  crc  errors. 

tx_aborted 

uint 

Count  of  transmitted  frames  aborted  or  flushed. 

tx_under 

uint 

Count  of  transmitted  frame  underruns. 

tx_abort_call 

uint 

Count  of  calls  to  qio_abort/flush. 

qiocurrx 

uint 

Current  number  of  frames  in  receiver  queue.  | 

qiomaxtx 

uint 

Maximum  number  of  frames  in  receiver  queue.  | 
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BAX  Data 
Poiiit 


TABLE  9  J  BAX  TELEMETRY 


qiocurtx 

uint 

Cumoit  number  of  frames  in  transmitter  queue. 

<]^maxtx 

uint 

Maximum  number  of  frames  in  transmitter  queue. 

pocdM 

uint 

Number  of  "pool  g^”  that  failed. 

r^_mioeeded 

uint 

Count  of  times  the  maximum  number  of  frame  retires 
has  been  exceeded. 

quitottx 

ulong 

Total  number  of  transmitted  frames. 

quitotrx 

ulong 

Total  number  of  frames  received  with  no  errors. 

tdatain 

ulong 

Total  number  of  data  bytes  received. 

tdataout 

ulong 

Total  number  of  data  bytes  transmitted. 

tdigi 

ulong 

Total  number  of  digipeated  frames. 

daytime 

ulong 

Total  number  of  SOmsec  intervals  that  have  expired 
since  system  startup. 

ulong 

Startup  time  in  seconds.  (UTC) 

Ftrilowing  are  counts  of  frames  types  defined  in  the  AX.25  protocol  (Ref.  2]. 


<I>  in 

ulong 

Number  of  "information”  fnunes  received. 

<RR>  in 

ulong 

Number  of  "receive  ready"  frames  received. 

<RNR>  in 

ulong 

Number  of  "receive  not  ready”  frames  received. 

<REJ>  in 

ulong 

Number  of  "reject"  frames  received. 

<DM>  in 

ulong 

Number  of  "disconnect  mode"  frames  received. 

<SABM>  in 

ulong 

Number  of  "set  asynchronous  balanced  mode"  (connect 
request)  frames  received. 

<DISC>  in 

ulong 

Number  of  "disconnect  request"  frames  received. 

<UA>  in 

ulong 

Number  of  "unnumbered  acknowledge”  frames 
received. 

<FRMR>  in 


ulong  ]  Number  of  "frame  reject”  frames  received. 


1  TABLE  93  BAX  TELEMETRY  POINTS  | 

BAXDirta 

Dot! 

Type 

Description 

<INV>  in 

ul(Mlg 

Number  of  'invalid*  frames  received. 

<UI>  in 

ulong 

Numbtt  of  "unnumbered  informatim”  frames  received. 

<I>  out 

ulong 

Numbtf  of  "infcHination*  frames  transmitted. 

<RR>  out 

ulcmg 

Number  of  "receive  ready*  frames  transmitted. 

<RNR>  out 

ul<xig 

Number  of  "lecdve  not  ready*  frames  transmitted. 

<REJ>  out 

ulong 

Number  of  "reject*  frames  transmitted. 

<DM>  out 

ulong 

Number  of  "disconnect  mode*  frames  transmitted. 

<SABM>out 

ulong 

Number  of  "set  asynchronous  balanced  mode”  frames 
transmitted. 

<DISC>  out 

ulong 

Number  of  "disconnect  request*  frames  transmitted. 

<UA>  out 

ulong 

Number  of  "unnumbered  acknowledge”  frames 
transmitted. 

<FRMR>out 

ulong 

Number  of  "frame  reject”  frames  transmitted. 

<INV>  out 

ulong 

Number  of  "invalid"  frames  transmitted. 

<UI>  out 

ulong 

Number  of  "unnumbered  information"  frames 
transmitted. 

1  TABLE  9.4  GENERAL  SYSTEM  TELEMETRY  POINTS  | 

1  Data  Point 

Data  Type 

Description  | 

LOGIN  Data  | 

Logins 

uint 

Number  of  user  logins.  | 

Logmits 

uint 

Number  of  user  logouts  (requested 
disconnects). 

ALogins 

uint 

Number  of  authorized  logins. 
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1  TABLE  9.4  GENERAL  SYSTEM  TELEMETRY  POINTS 

Data  Type 

1  Description 

UALogiii 

uint 

Number  of  unauthorized  login  attempts. 

UALtime 

UTC 

Unauthorized  login  attempt  time  stamp. 

Uuser 

array  of 
Callsign_ 
Type 

List  of  Undesirable  Users. 

1  MAILBOX  Data 

RMaU 

uint 

Count  of  received  mail. 

SMail 

uint 

Count  of  sent  mail. 

StMail 

uint 

Count  of  stored  mail. 

Stor 

ulong 

Amount  of  storage  used. 

1  Craununkatioii  Syston  Data 

Receiver 

boolean 

Receiver  A  or  B  selected. 

Transmitter 

boolean 

Transmitter  A  or  B  selected. 

Mode 

boolean 

Spread  Spectrum  turned  On  or  Off. 

Atten 

uint 

Attenuation  Level  1  through  8  selected. 

1  Digital  Control  System  Data 

DCS 

boolean 

DCS  A  or  B  selected. 

SWver 

uint 

Software  version  in  use. 

date 

UTC 

Current  satellite  date  and  time. 

SEUc 

uint 

ED  AC  (error  detection  and  correction)  SEU 
(single  event  upset)  count. 

SEUt 

UTC 

Start  time  for  EDAC  SEU  time. 

SEUlt 

UTC 

Time  of  latest  EDAC  SEU. 

RAMw 

ulong 

Address  of  next  RAM  cell  to  be  "washed". 

As  tbe  tckmetry  g^Mring  module  crnnirimes  eadi  nnuid  of  readings,  it  iqidates  a 
file  die  "current  telemetiy*  n^iich  is  accessible  to  the  automatic  control  nuxlule.  The 
automatic  control  module  makes  use  of  this  data  in  its  autonomous  control  of  the  satellite 
hardware  systems.  The  telemetry  gathering  module  also  stores  telemetry  data  in  a 
telemetry  histmy  file,  which  will  continue  to  grow  and  store  past  data  until  it  is  purged 
by  a  command  from  the  ground  ccmtrol  station,  or  it  reaches  a  pre-detormined  maximum 
size.  If  the  maximum  file  size  is  exceeded  before  the  file  can  be  downloaded  and  then 
purged  by  the  ground  control  station,  the  most  recent  entries  for  each  data  point  will  be 
maintained,  and  older  entries  deleted,  in  order  to  control  the  size  of  the  file.  The  ground 
OHitTol  station  will  use  this  larger  telemetry  file  to  analyze  trends  in  satellite 
performance,  and  to  make  control  decisions  beyond  the  scope  of  those  made  by  the 
automatic  control  module.  The  telemetry  gathering  module  will  also  maintain  shorter 
telemetry  files  containing  data  which  may  be  of  interest  to  the  amateur  radio  users  who 
access  the  satellite  mail  box  system.  These  files  are  stored  in  the  mail  area  with  the  file 
name  "USRTELEM.xxx". 

B.  AUTOMATIC  CONTROL  MODULE 

The  AUTO_CONTROL  module  carries  out  periodic  functions,  such  as  battery 
conditioning,  on  a  time  scheduled  basis.  It  also  carries  out  aperiodic  functions.  As 
indicated  in  the  previous  section,  the  AUTO_CONTROL  module  makes  use  of  the  data 
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collected  by  die  tdemetry  gathering  module  to  make  decisions  about  the  control  of  the 
satellite  hardware.  It  also  maintains  a  "time_tagged"  command  buffer  which  lists 
activities  which  diould  take  place  at  a  particular  time  in  the  future.  This  command 
buffer  is  updated  by  the  GROUND_CONTROL  module  as  a  result  of  ground  control 
statitm  commands.  The  Digital  Control  System  design  includes  hardware  timers  which 
can  be  programmed  by  the  automatic  ctmtrol  module  to  interrupt  the  microprocessor  at 
designated  time  intervals  to  initiate  periodic  events  or  to  produce  a  set  of  one-time-only 
interrupts  to  initiate  evoits  controlled  by  the  command  buffer.  Software  timers  may  also 
be  used  for  some  of  the  automatic  control  module  functions. 

Most  of  the  control  functions  carried  out  by  the  automatic  control  module  will 
likely  be  cased  on  a  "table  look-up"  system.  When  a  timer  interrupt  occurs,  an  interrupt 
vector  table  will  contain  the  address  of  the  appropriate  subroutine  needed  to  carry  out  the 
scheduled  activity.  Another  table  of  subroutine  addresses  will  be  indexed  based  on 
combinations  of  telemetry  readings  which  call  for  some  action  to  be  taken.  These 
subroutines  and  tables  will  be  developed  as  more  is  learned  about  the  specific 
requirements  of  the  hardware  as  it  is  designed. 

Table  9.5  lists  some  possible  functions  of  the  automatic  control  module  which  have 
been  identified  thus  far.  The  EPS_DRIVER,  COMM_DRIVER  and  DCS_DRIVER 
modules  contain  the  software  drivers  required  for  direct  digital  control  of  the  electric 

r  _ 

power  system,  communications,  and  digital  control  system  hardware.  The  services  of 
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these  modules  will  be  accessed  as  necessary  by  the  automatic  control  module  in  order  to 
carry  out  functions  listed  in  Table  9.S. 


TABLE  9.5  AUTOMATIC  CONTROL  MODULE  FUNCTIONS 


f^inction 

1  Description 

Electric  Power  Supply 

Control 

Turn  hardware  components  off  and  on  as 
necessary  to  conserve  power,  allow  battery 
ctNiditioning,  etc. 

Condition  Batteries 

Periodically  discharge  and  recharge  batteries  in 
order  to  prcvwit  battery  "memory". 

Systems  Test  Management 

Carry  out  periodic  systems  checks  in  addition  to 
normal  telemetry  gathering.  Save  test  data  for 
download  to  ground  control  station. 

Communications  Control 

Transmitter/Receiver  component  select. 

Transmitter  Output  Power 
Control 

Set  level  of  transmitter  power. 

Automatic  Subsystem  Select 

Select  alternate  subsystem  upon  time-out  waiting 
for  response  of  a  primary  subsystem. 

Real  Time  Clock  Control 

Set  and  remove  times  for  periodic  interrupts. 

Send  Messages 

Send  periodic  messages  to  the  ground  control 
station  via  BAX. 

Cq>y  Vital  Statistics 
» 

Transfer  vital  operating  system  information  to 
alternate  processor. 

RAM  Wash 

Periodic  reading/writing  of  system  RAM  to  enable 
Error  Detection  and  Correction  functions. 

Digital  Control  System 

Health  Check 

Periodic  signal  to  EPS  to  ensure  proper  operation 
of  active  DCS.  EPS  will  disable  a  malfunctioning 
DCS  board  and  "boot”  the  alternate  when  the 
proper  signal  is  not  received  on  time. 
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1  TABLE  9.5  AUTOMATIC  CONTROL  MODULE  FUNCTIONS  | 

f^inctkm 

1  Description 

User  Lockout. 

Message  to  data  transfer  module  locking  out  all  or 
new  users. 

C.  GROUND  CONTROL  MODULE 

The  GROUNDjCONTROL  module  contains  the  command  interpreter  and  the 
functionality  required  to  carry  out  commands  transmitted  by  the  ground  control  station 
at  NFS.  Ground  control  packets  will  be  passed  directly  to  the  ground  control  module  by 
BAX,  since  they  will  be  addressed  specifically  to  the  ssid  (subsystem  identiflcation 
number)  for  this  module.  All  ground  station  comnumds  will  be  subject  to  verification 
by  including  a  time  varying  password.  The  PASSWORD_CONTROL  module  will  keep 
track  of  the  current  password  aboard  the  satellite,  and  will  provide  this  information  as 
necessary  to  the  ground  control  module.  Similar  software  will  track  the  current  password 
for  the  ground  control  station.  There  will  be  facilities  for  determining  the  current 
password  aboard  the  satellite,  in  case  the  two  systems  lose  synchronization  for  any 
reason.  The  specification  of  the  password  control  module  contains  proprietary 
information,  and  will  not  be  published  for  general  release. 

Once  a  command  has  been  received  from  the  ground  control  station,  the  password 
has  been  verified,  and  the  command  has  been  interpreted,  the  ground  control  module 
dther  carries  out  the  command  directly,  or  communicates  with  other  software  modules 
as  necessary  to  utilize  their  C2q)abilities.  A  ground  command  may  involve  updating  the 
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time-tigged  oommand  list  of  die  automatic  oontnd  module,  or  varying  the  time  intervals 
for  periodic  events  carrmd  out  by  the  automatic  control  or  telmnetry  gathering  modules. 
It  may  initiate  a  one-dme-only  corrective  action,  or  change  a  basic  system  parameter. 
Smne  ground  station  commands  simply  involve  die  acquisition  of  informatitm  for  use  by 
the  ground  control  statitm  software  or  personnel. 

Some  possible  functions  of  the  ground  control  module  which  have  beoi  identified 
dius  for  are  listed  in  Table  9.6.  The  PRIMrnVE_SW_LOADER  module,  which  is 
actually  the  commercial  program  "PHTX*,  is  designed  to  work  directly  with  BAX  to 
upload  software.  This  module  will  be  utilized  by  the  ground  control  module  when  a 
command  is  received  to  upload  new  software.  In  this  way,  the  flight  software  can  be 
updated  as  necessary  to  correct  errors  or  increase  functionality. 


1  TABLE  9.6  FUNCTIONS  OF  THE  GROUND  CONTRC*  .  MODULE  | 

F^mction 

Description 

Command 

Interpretation/Validation. 

Process  a  received  ground  station  command. 

Update  Time-Tagged 
Command  Buffer. 

Schedule  events  to  be  carried  out  at  a  future  time 
by  the  automatic  control  module,  or  delete  evoits 
from  the  command  buffer. 

Set  Omtrol  Rates. 

Update  time  intervals  or  list  of  periodic  functions 
of  the  automatic  control  module. 

Set  Telemetry  Polling  Rates. 

Update  time  intervals  used  by  the  telemetry 
gathering  module  for  particular  telemetry  points. 

Add  or  delete  telemetry  points. 
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TABLE  9.6  FUNCTIONS  OF  THE  GROUND  CONTROL  MODULE 


Desolption 

Software  UjAoad. 

Upload,  and  store  new  or  updated  software 
modules. 

Run  Software. 

B^in  using  newly  uploaded  or  alternate  software 
module. 

Dd^  Software. 

Delete  specified  software  module. 

Copy  Software. 

Copy  verified  software  to  altnnate  processor. 

Boot  ROM. 

Rdxwt  PANS  AT  from  ROM  (read  only  memory). 

Boot  OS. 

Load  a  new  operating  system  and  transfer  oori 

Read  OS  Information. 

Download  the  current  operating  system  pointers 
and  parameters. 

UstMaU. 

Download  a  list  of  all  mail  messages  and  bulletins 
currently  stored. 

Dump  Mail. 

Download  system  bulletins  and  mail  in  bulk. 

Post  Bulletin. 

Post  a  system  bulletin  in  the  mailbox  area  for  all 
users. 

Remove  Bulletin. 

Remove  a  system  bulletin. 

Purge  Mail. 

Purge  all  or  selected  mail  from  the  mailbox 
storage. 

Read  Currrat  Telemetry. 

Download  the  current  telemetry  file  maintained  by 
the  telemetry  gathering  module. 

Read  Stored  Telemetry. 

Download  the  telemetry  history  file  maintained  by 
the  telemetry  gathering  module. 

Purge  Stored  Telemetry. 

Delete  all  or  portions  of  the  telemetry  history  file. 

Read  Data. 

Download  an  arbitrary  block  of  data,  specified  by 
address  pointer,  from  the  file  storage  area  or 
system  RAM. 

Set  Real  Time  Clock. 

Set  satellite’s  real  time  clock  to  a  specified  time. 

Read  Real  Time  Clock. 

Download  current  time  on  satellite’s  real  time 
clock. 
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TABLE  9.<  FU^K:110NS  OF  1HE  GROUND  CONTROL  MODULE  | 

nUKtiOB 

1  Deacriptioa 

|05S^^ES2SI^S^Sm 

Turn  power  on/off  to  a  particular  subsystem. 

Condition  Batteiy. 

Diachaige/Recharge  specified  batttay. 

Tridde  Charge  Battery. 

Triclde  diarge  q)ecified  battery. 

Charge  Battery. 

Quick  charge  of  q)ecified  batt^. 

Sdect  Battery. 

Sdect  ^)ecified  redundant  battery. 

Select  Receiver. 

Sdect  specified  redundant  recdver. 

Select  Transmitter. 

Sdect  specified  redundant  transmitter. 

Select  Processor. 

Select  specified  redundant  digital  control  system 
board. 

Set  Mode. 

Sdect  communications  mode:  spread  spectrum  or 
BPSK. 

Set  Maximum  Transmitter 
Power. 

Set  maximum  allowable  amplitude  of  transmitter 
power. 

Set  Attmmation. 

Set  attenuation  level  of  the  active  transmitter. 

Switch  to  Super  User  Mode 

Functions  requiring  super  user  mode  are  ttxl. 

Exit  Supo*  User  Mode. 

Download  Event  Log  maintained  by  the  event 
logging  module. 

Purge  Evoit  Log. 

Delete  all  or  portions  of  the  event  log,. 

Read  Time-Tagged 

Command  Buffer. 

Download  the  time-tagged  command  buffer. 

Purge  Time-Tagged 

Command  Buffer. 

Delete  the  entire  time-tagged  command  buffer. 

User  Lockout. 

Message  to  data  transfer  module  locking  out  all  or 
new  users. 
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D.  EVENT  LOGGING  MODULE. 

The  purpose  of  the  EVENT^LOGGING  module  is  to  maintain  a  history  of  all  the 
significant  events  s^ch  luyjpen  and  commands  which  are  carried  out  aboard  the  satdlite. 
It  is  hoped  diat  this  event  log  will  be  hdpful  in  tioubte  shooting  problems  aboard  the 
satellite,  or  merely  in  studying  its  operation.  The  event  logging  module  differs  from  the 
tdemetry  gathering  module  in  one  major  req)ect.  The  tdemetry  gathering  module 
periodically  polls  the  hardware  and  other  software  modules,  gathering  a  predetermined 
list  of  q)ecified  data.  The  event  logging  module  waits  to  receive  evoit  messages  from 
othm*  modules,  informing  it  of  aperiodic  evoits  which  are  deemed  significant  in  some 
way. 

A  list  of  "significant*  events  vkill  need  to  be  detomined,  so  that  the  exact  nature 
of  the  evoit  messages  can  be  defined  in  the  software  specification.  Some  possible  events 
include  the  occasion  of  a  full  mailbox,  a  telemetry  reading  beyemd  the  "operating  range" 
(this  will  also  be  listed  in  the  telemetry  files,  of  course,  but  may  stand  out  more  here, 
or  be  associated  with  some  other  event  which  will  make  trouble  shooting  and  correction 
easier),  user  connections  lost  because  the  transmitter  has  been  shut  down  for  power 
reasons,  etc.  An  event  log  entry  will  also  be  made  each  time  an  automatic  command 
function  or  a  ground  control  command  is  carried  out.  The  exact  format  of  the  evoit  log 
entries  will  be  develtqped  as  the  list  of  significant  events  and  useful  information  is  further 
defined. 
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X.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  THE  USE  OF  ESTELLE 

The  fbnnal  description  tedinique,  Estdle,  has  i»oven  to  be  a  valuable  tool  in 
Gitatiiig  a  software  qiedfication.  Its  medKxls  of  defining  state  machine  bduivior  and  its 
diannel  and  message  definitions  have  provided  a  unique  way  of  visualizing  a  system,  and 
seeing  how  all  of  the  pieces  fit  together.  The  various  levels  of  abstraction  greatly 
fticilitate  die  advancement  of  a  project,  even  when  all  details  are  not  yet  known.  When 
details  aS  known,  Estelle  provides  amide  means  of  qiecification  at  the  lowest  possible 
levels,  and  the  fiexibility  to  define  algoridims  both  simple  and  complex. 

In  otda  to  make  Estelle  even  more  useful  in  this  project,  a  few  modifications  have 
been  made  to  it.  For  instance,  rince  "C"  has  already  been  chosen  as  the  implementation 
language,  a  few  data  types  have  been  defined  to  more  closely  match  familiar  structures 
in  "C”.  Array  indices  start  at  0  in  this  ^lecification,  as  they  do  in  "C”.  Multiple 
dimension  arrays  are  indexed  by  multqile  sets  of  brackets,  ”var[i](j]”,  rather  than  by 
multiide  indices  widiin  one  set  of  brackets,  "vaifi,  j]".  The  names  of  the  primitive  data 
types  are  borrowed  from  "C":  "uchar",  *uint  "and  "ulong".  Many  of  the  primitive 
fimctkms  and  procedures  are  functions  familiar  to  "C"  prc^rammers.  In  addition, 
various  font  modifkations  have  been  used  to  make  elements  of  the  Estelle  and  Pascal 
syntax  stand  out,  so  that  their  meanings  are  mcne  obvious  in  the  context.  Bold  is  used 


to  indicale  leserved  woids,  uaer-<lefiiied  data  types  begin  with  Capital_Letters,  constants 
are  written  in  UaiicSt  etc. 

Many  oi  the  nxxre  cmnid»  amiabilities  of  Estdle  are  not  utilized,  since  they  are 
aomoi^  confusing  and  are  not  needed  to  make  clear  the  intended  behavicff  of  tlw 
software  being  defined.  The  greatest  drawback  of  Estelle  is  tte  qiecilication  of  Estdle 
itadf,  8].  [Ref.  8]  is  very  difficult  to  read  and  sometimes  impossible  to 
understand.  For  those  interested  in  using  Estdle  in  future  software  specification  projects, 
it  is  recommended  that  only  the  Annexe  be  read.  These  contain  all  the  information 
needed,  as  well  as  adequate  examples  to  provide  understanding  of  how  this  language  can 
actually  be  used. 

B.  RECOMMENDATIONS  FOR  FllRTHER  WORK 

This  thesis  provides  a  prdiminary  specification  for  the  flight  software  of  the  Petite 
Amateur  Navy  Satellite.  As  much  information  as  is  currently  available  concerning  the 
high-level  operational  requirements  of  the  satellite  has  beoi  included.  A  software 
architecture  has  been  provided  which  defines  the  individual  software  modules  and  their 
interfaces.  Detailed  definititms  for  die  bodies  of  the  communications  and  ftle  transfer 
protocol  modules  have  beat  developed. 

There  is  obviously  much  work  remaining  to  be  done.  The  module  body  definitions 
for  the  tdonetiy  gathoing,  analog  to  digital  conversion,  automatic  control,  ground 
control,  electronic  power  system  driver,  communicaticm  driver,  digital  control  system 
driver,  and  event  logging  modules  mu^  be  developed.  The  channel  types  and  message 


102 


imwftwM  between  tfiese  remaining  modules  and  between  them  and  die  existing  modules 
must  be  defined  in  greater  detail.  Onoe  die  oonqilete,  detailed  ^wcification  is  available 
for  die  entire  flight  software  system,  the  actual  code  must  be  written  and  tested.  The 
ground  software  and  the  bootstrap  software  must  be  qiecified  and  coded,  and  the 
interfoces  between  these  programs  and  the  flight  software  must  be  tested.  Hardware 
designs  must  be  completed  and  tested  before  any  software  qiedficadons  can  actually  be 
finalized.  A  start  has  been  made,  and  the  beginnings  of  a  road  map  have  been  drawn. 
Much  more  effort  will  be  requited  before  this  project  is  completed. 
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AffENDK  A  -  ESTELLE  SOFTWARE  SFECmCAIlON 


^pedlleatioo  Fli^t_Software; 


type  { Primitiyc  Types  } 

{  Note:  the  notatioA  ’Oxhh’  is  used  to  refer  to  } 
{  hexadedmal  numbers,  with  the  h's  } 

{  rq)resenting  the  hex  digits  0..F.  The  number  } 

{  of  bytes  in  each  hex  number  is  the  number  of  } 

{  digits  divided  by  2.  } 

udiar  »  0x00..0xFF;  {  8  bits  of  binary  ds^  or  1  byte  unsigned  int^er  or  } 

{  1  ASCn  character.  } 

uint  « (ifx0000..QxFFFF;  { 2  byte  unsigned  int^er  } 

ukmg  a:  0x00000000.  .OxEPFFFFFF;  {  4  byte  unsigned  integer  } 

int  B  .  .;  { Festive  and  N^ative  int^ers  as  defined  on  } 

{  implemoitation  hardware.  } 

const  { ’Global*  Cmistant  Declarations  } 

max  JUeJengOi  »  any  ulong;  {  Maximum  length  of  a  file  onboard  the  satellite  } 

maxjncdl  -  any  uint;  {  Maximum  pieces  of  mail  in  Select  list  } 

pas^rdjength  =  any  uchar;  {  Numbor  of  characters  in  the  password.  } 

max _pdat  =  2047;  {  Max  number  of  bytes  in  the  data  field  of  a  packet. } 

max  Jdat  -  256;  {  Maximum  length  of  data  field  in  a  BAX  firame.  } 

maxUnks  » 30;  { Max  channels  allowed  by  BAX.  } 

pansasjeaU  =  any  CallsignJT^;  { Pansat’s  call  sign  } 

rq)S_c(^  B  any  CallsignJType;  { NFS’  call  sign.  } 


nojerror  =  0x00; 

erjn Jbfmedjxnd  =  0x01; 

er_bad_cominue  =  0x02; 

er_server Jsys  =  0x03; 

er_no^suchJile_number  ==  0x04; 

erje1axion_arqay  =  0x05; 

erjnandiOory Jieldjnissing  »  0x06; 

erjio jflt  B  0x07; 

er _pooHy Jbrmed_sel  b  0x08; 

erjUreadyJodBed  b  0x09; 

erjio_m^_destination  -  OxOA 

erjikjconidete  b  OxOC 

er  no  room  =  OxOD 


{  Errmr  Codes 

{ Incorrect  or  unexpected  command 


{  OxOB  was  a  rq)eat  of  0x05 


} 

} 
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er^badjieader 

«  QxOE; 

erjieaderjdieck 

-OxOF; 

er_bodyj^ieck 

-t  QxlO; 

er jpermisrion_demed 

»  0x90  ; 

type 

tjwint.Reoofd  ~  { 

Tcieiii*Data  Type  « 

EPS.Cmd Jype 
EPS_RespJlSpc  » 
Coam_C^_Type  « 
Ccmm.Reapjrype  » 
DCS_Cind_’iVpc  * 
DCS_Re^_Tipc  = 

Sat_Cind_Typc  = 

Sat~Re9_Type  = 
Evcnt_R^ort_Type  = 

Callsign_Type  s  aiTay[6]  of  uchar; 
Byte_StiUig  =  "  amy[  ]  of  uchar 


{  PANSAT  ifiecific;  not  in  FTLX). 
{  Global  Type  Dedaratioos 


To  be  detemnined* 


} 

} 


Pdat.Len 

Fdat_Len 

Locl^t.Type 

FnuneJType 
Link  ^te 


Cause 

PasswordJType 

File_Typc 

Pda^ 

Fdala 
Num_Mail 
IMiecticm 
Packet JType 
lengthjsb: 
hi: 
info: 
ei^; 

linkjl^ 


{  Any  evoi  number  of  hex  digits  surrounded  } 
{  by  double  qwMes.  Refers  to  raw  binary  } 

{  data  matching  the  pattern  of  the  hex  digits} 

{  and  of  the  same  length.  } 

0..max jpdat;  {  Number  of  bytes  of  info  in  a  packet.  } 

0..inax  Jiat;  {  Number  of  bytes  of  info  in  a  frame.  } 

(all,  new)\  {  Each  member  of  an  enumerated  type  is  assumed^ 
{  to  be  associated  with  a  distinct  uchar.  } 

(qat_data,  qat^state,  qatjii)', 

(qasjconnect j>end,  qasjconnected, 
qasjcontieaing,  qasJUsamnected, 
qasjUscormecting,  qas Jhanereject); 

(gacjocal,  qacjtmote,  qac_remotefrmr, 
qacjimema); 

arny{passwoni_kngth]  of  uchar; 
arniy[OTax_dte_fengfh]  of  uchar; 

aiTay[niax  jxiat]  of  uchar;  { Info  field  of  a  packet  } 

aiTay[max  of  uchar;  { Info  field  of  a  frame  } 

0..maxjnail; 

(l^,  right); 
record 


uchar; 

uchar; 

Pdata; 


0  ..  maxUnks  - 1; 
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Nuiie_l>pe 


»  arfay(12]  of  uchar,  {  DOS  file  name.  Qiaracter  in  9th 
{  position  must  be 


File.Lut 

BitJType 

«  arrayt  ]  of  Name  Type;  {  Variable  len  array  of  file  names. 
=  0..1; 

Contiol_Block 

s  record 

{  Includes  (Mily  BAX  fields  which  are  used 

link: 

uint; 

{  ’channel*  in  BAX  manual 

kind: 

FrameJType; 

{  ’type’  in  BAX  manual 

Instate: 

Link_State; 

{  ’state’  in  BAX  manual 

why: 

Cause; 

{  ’cause’  in  BAX  manual 

my_call: 

Callsign_Type; 

{  AX25_ADDR  or  AX25_CALL 

my_ssid: 

uchar; 

{  in  BAX  manual 

his_call: 

CallsignJType; 

{  Client’s  Call  sign 

his_ssid: 

uchar; 

{  Client’s  SSID  •  may  not  be  needed 

tl: 

udiar; 

{ tl  frame  ACK/NAK  timeout  timer  value 

maxframe: 

uchar; 

{ frame  sliding  window  size 

retry: 

uchar; 

{  maximum  number  of  retries  for  an  out  frame 

paclen: 

end; 

uint; 

{  maximum  size  of  info  field  in  outgoing  packet 

{  Ctuumel  IMinitioiis  } 

dumnd  AbitnctJBax_Channel(  Bax_Eiid,  Data_Transf(»_End); 
by  Bax^End: 

9txjinput(  m_cb:  Control_Biock;  idata:  Fdata;  dalal:  Fdat^Len); 
by  DataJlVantferJEnd: 

^_daim(  ouT_d>:  Control_Block;  grab:  uchar); 

<iBXjdata(  link;  Link.Type;  out_d>:  Cmtrol^Blo^;  odata:  Fdata;  datal:  Fdat_Len); 
qaxjHisyC  link:  LinkJType); 

^_oon_aq>t: 

qax_oon_rg; 

link:  LinkJType); 

qaxjoonnecK  outjd>:  C^trol_Block); 

qBx_ui(  link:  LinkJI^pe;  out_d):  ControlJBlock;  odata:  Fdata;  datal:  Fdat_Lra); 
^_diaconnect(  link:  LinkJType;  wait:  botdean); 

duumel  Abstract JPacket_Channel(  DataJTransfer_End,  Packet_Transfer_End); 
by  DataJTiansfer_Eii^: 

oonnection(  callsign:  Callsign JType); 
disconnect; 

command j»cket(  command:  Packet  JType;  datal:  Pdat_Len); 
by  Packet JTransfer_End: 

reqxMlsejncketT  response:  PactetJType); 

duumd  Mailbox_Access_Channd(  Packet JTransferJEnd,  Mailbox_End); 
by  PacketJTTansfer_&id: 

active_d_req(  cUent^call:  Callsign  JType);  {  Does  client  have  an  active  select  list?  } 
mailjium_teq(  client_call:  Callsign  JType;  mail_number,  length:  ulong); 
mail_recvf  nudl_number,  offset,  length:  ulong;  mail:  Pdata); 
mail_close_teq(  mail_number,  offset;  ulong;  req^resp:  bootean); 
mselect_teq(  clientj^:  Callsign  JType;  select_struct:  Pdata); 
mail_teq(  client_call:  Callsign JT^;  mail_number,  offset:  ulong); 
di_ack(  cliait_adl:  Callsign Jl^pe;  inail_number:  ulong); 
dir_/eq<  client^caU:  Callsign_T^;  mail_number;  ulong); 
mail_dd_teq(  client_call:  Callsign  JType;  mail_number,  Imgth:  ulong); 
by  Mailbox JEnd: 

active_sl_resp(  si:  boolean);  { true  if  client  has  an  active  select  list.  } 

mail_num_rKp(  mail_number,  offset:  ulong;  error_code:  uchar); 

mail_recv_re^  aror.code:  uchar); 

mail_close_ie^  error_code:  uchar); 

mail_send(  mail_number,  length:  ulong;  mail:  Pdata); 

mselect_T^  num_sel:  Num_Mail;  mor_code:  uchar); 

mail_re^  mail:  Pdata;  mail_number,  loigth:  ulong;  no_al:  boolean); 

directory(  ten:  Pdat^Len;  dir:  Pdata;  no_al:  boolean); 

inailjtel_req;>(  error_code:  uchar); 
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ckuMci  ldUBto_A<inin_Chaniid(  Contnd_End,  Mailbox_End); 

Control J^: 

liat_niail(  bultetins,  messages,  from,  to:  bookan;  callsign:  CaUsign_Type); 
p08tjnilletin(  bull^:  NameJType); 
delete jNiltetin(  bulletin_name:  NameJType); 

p(ttge_inail(  all,  from,  to:  boolean;  <^sign:  Callsign_Type;  post_tinie:  ulong); 
by  Mailbox^End: 

mailjist(  num_fUes:  uint;  mail:  File_List); 
full_maitbox; 

dumnd  Telem^_SU»age_Channel(  Telem^JEnd,  Mailbox_End); 
by  Telmnetry_^: 

stoie_us^_telem(  telem:  NameJType); 
delete_user_telem(  tdem_file:  NameJType); 

duumel  Passworcl_ContrDl_Channel(  Control_End,  Password_End); 
by  C(Mitrol_End: 

passwordjchange_request; 
request^cunentjMissword; 
by  PasswoiidJEnd: 

passwQid(  pswd:Password_Type); 

duumel  Data_Transfer_Control_Channel(  Control_^d,  Data_Transfer_End); 
by  Cootrd_End: 

change_paiams(  out_cb:  Control_Block); 
lockout(  IJdnd:  Lockout JType); 
unlock(  l_kind:  Lockout_T3^); 
tiansmitter(  off:  boolean); 
by  ControUedJEnd: 
acknowledge; 

duumel  Tclcmctry_Control_Channel(  Control_End,  Telemctry_Gather_End); 
by  Control_End: 

add_point(  point:  Tpoint_Record ); 
ddetej)oint(  point:  Tpoint_Record ); 
change_timing(  point:  Tpoint^Record); 
iead_cuirait_telem; 
iead_stoied_telem; 
purge_stoied_telem; 
by  TeienMetry_Galher_End: 

ackjx)int_change(  error:  uchar); 
curraitjdemf  telem:  CurJTdemJType); 
stored_tdem(  telem:  FuUjTelemJType); 
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A/D_CoiitiQl_Chamid(  Command.End,  A/D_Conveiter_End); 
by  Comnuind^End: 

w»rmi9(devioejiuiii:  uchar); 
slart_ooiivtnk»(  tdemjwint:  uchar); 
iqKvtjdataC  tdmjmint*  udiar); 
by  A/D_poiivaler_Eiid: 

deviw_itady(  dewioe.num:  uchar); 

<laii_iaKly(  tetemjxmt:  uchar); 
lelenjda^  t.data:  Tdem_DataJI>pe); 

SW_Load_Coatrol_,Qiannd[(  Cootiol_,Eiid,  Loader_End); 
by  Goatnd.Eod: 

i^AoadC  newjK>ftwaie:  NameJType;  sw_address:  ulong); 
by  Loader_End: 

uid<ndj)egin(  fiew_aoftware:  NameJType); 
v^oad_complete(  new^sofkware:  Naine_T^); 

fiMnnrf  EPS_Contn)l_Channel(  Control_End,  EPS_Driver_End); 
by  Contr^_Eiid: 

q)s_ciiid(  cmd:  EPS^CmdJType); 
by  EPS_I>rivcr_Eiid: 

epsjtspC  le^:  EPS_RespJI>rpe); 

fhannd  CcHnm_Control_Chaiind(  Omtrol^  *  iid,  Comm_Driver_Eiid); 
by  Control JBfid: 

oommjcind(  cmd:  Comm_Cmdjrypi.^ 
by  Comm_l>river_End: 

oomm_ie^  ieq>:  Comm_Resp_Type); 

channel  DCS_Control_Channd(  C(mtrol_End,  DCS_DTiver_End); 
by  ContR^End: 

dcsjcmidC  cmd:  DCS_CmdJiype); 
by  DSC_Driva_End; 

re^:  DCSJle^JI^pe); 

duumd  Satdlite_Contiol_Channel(  Giound_C<mtrol_End,  Auto_Control_End); 
by  Ofound_COTtiol_^: 

aat_cmd(  cmd:  Sat^CmdJType); 
by  Autt>_Contiol_End: 

aat_re^  re^:  Sat_Re^_Type); 

Aannri  EventJLog_Channd(  Event_End,  Log_End); 
by  Event_End: 

event_tqK>it(  report:  Event_Rq)ort_Type); 


no 


{  Gtobal  ftuKtim  decfaurations  } 

ftuKliOB  GETjnME;  uloQg;  {  Returns  a  32-bit  unsigned  int^er  indicating  the  } 

priadtffe;  {  number  of  seconds  since  January  1,  1970.  } 

ftmdloD  C_BIT_SHIFT(  d:  Direction;  num:  uchar;  b:  udiar):  uchar; 

primitive  {  Bit-wise  ^ft  of  the  byte  qiecified  by  ’b*  in  the  } 

{  direction  qiedfied  by 'd*.  'num'  qwciOes  the  } 
{  number  of  bit  positions  to  shift.  Returns  a  1  } 

{  byte  answer.  } 

ftmction  I_BIT_SHIFT(  d:  Direction;  num:  uint;  b:  uint);  uint; 

primitive;  {  Bit-wise  shift  of  the  uint  q)ecified  by  ’b’  in  the  } 

{  direction  ^)ecified  by  *d’.  ’num*  specifies  the  } 
{  numbo^  of  bit  portions  to  shift.  Returns  a  2  } 

{  byte  answer.  } 

functiini  C_BIT_AND(  a,  b:  uchar):  uchar; 

primitive;  {  Returns  Bit-wise  AND  of  the  bytes  ’a’  and  ’b’.  } 

functkm  I_Brr_AND(  a,  b:  uint):  uint; 

primitive;  {  Returns  the  bit-wise  AND  of  the  uints  ’a’  and  ’b’.  } 

function  GEr_LSB(  number:  uint):  uchar;  {  Receives  a  16  bit  number  and  returns  the  } 

primitive;  {  least  significant  8  bits.  } 

ftmction  GET_MSB(  number:  uint):  uchar;  {  Rceives  a  16  bit  number  and  returns  the  } 

primitive;  {  most  significant  8  bits  } 

function  INT(  short:  uchar):  uint;  {  Receives  an  8  bit  unsigned  number  and  extends  it  t() 

inrindtive;  {  16  bit  unsigned  number  by  prqp^ding  8  O’s.  } 

procedure  QAX_CLEAN_CB(  cb:  Control^Block); 

iwimitive;  { Initializes  all  fields  of  the  control  block  structure  } 

{  to  0.  This  is  a  procedure  provided  by  BAX.  ) 

ftinctitm  FORMAT_EVENT_REPORT(  event:  uint;  time:  ulong):  Event_Report_Type; 
extonal;  {  This  function  prepares  an  Evrat_R^ft  to  be  sent  } 

{  to  the  EVENT_L(XJ  module.  This  function  is  } 
{  external  since  the  structure  of  the  } 

{  Event_Report_Type  has  not  yet  been  determined. } 
{  The  parameter  list  may  have  to  be  modified  whoi} 
{  this  Unction  is  further  defined.  } 
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{  Module  Header  Definitions 


module  FRlMrnVE_AX2S_TYPE  systemprocess;  {  BAX. 

ip 

bax:  anay[4]  of  AbstniCt_Bax_Chaniiel(  Bax^End)  indiriduai  queue; 
end; 

module  DATAJTRANSFER_TYPE  qrstcnqNroccm;  {Between  BAX  and  FTLX) 
ip  ” 

pc:  array[max2iiiib]  of  Abstnict_Packet_Qiannd(  Data_Tiansfer_End) 

individual  queue; 

bax:  Abstract J3ax_Channel(  I>ata_Tran5fer_End)  individual  queue; 
cc:  aiTay[2]  ^tajmnsfer_^ntrol_Channd(  Data_Transfer_End) 

coounmi  queue; 

el:  Event_Log_Channel(  Event_End)  common  queue; 

end; 

module  PACKET_TRANSFER_TYPE  $ystemprocess(  link:  Link.Type);  {  FTUO 

ip 

pc:  Abstract_Packet_Channel(  Pack^_Tiansfm_End)  individual  queue; 

me:  Mailbox_Access_Channel(  PacketJTransfer^End)  individual  queue; 

el:  Event_Log_Channel(  Event_End)  common  queue; 

end; 

module  MAILBOX_CONTROL_TYPE  systanprocess; 

ip 

me:  arrayCmox/i/ifo]  of  Mailbox_Access_Channel(  Mailbox_End) 
indi^dual  queue; 

cc:  aiTay|2]  of  Mailbox_Admin_Channel(  Mailbox_End)  emnmon  quaie; 

ts:  Tdenietry_Stroage_Channel(  Mailbox_End)  individual  queue; 

el:  Event_Log_Channel(  Event_End)  common  queue; 

end; 

module  PASSWORD_CONTROLjrYPE(  firstjxissword:  Password_Type; 

shuffle:Shuffle_Type);  systonprocess; 

ip 

cc:  aiTBy[2]  of  Passwoid_Control_ChanneI(  Password_End)  ccunmon  quaie; 

d:  Hvent_Log_Channd(  Event_End)  ennmon  queue; 

end; 


{  Atttonittic  HomdasqM^  Fimctions  } 


TYPE  nmmvnnm\ 

IF 

bn:  AbitnctJBn.ChtiiiidC  DatajrnosferJEad)  fadHridiial  queue; 
aod:  OataJTinsfo^Coiitn^  Coii^_Bnd)  iadDvMhijU  queue; 

act:  TOemetry_Cootid_Cluuiiid(  Cootrol.Eod)  iaAridud  queue; 
aqp:  FusiindJCoiitrd jbiannd(  Control_Eiid)  faidhrldual  queue; 
acm:  Mayb(n.Adiiiin_.Qiaiiiid(  Cootrd_Eiid)  ludlvldnal  queue; 
ace:  EPSjCola^ j(^aind(  Cootrol.E^  faifividual  queue; 
aoom:  OMrajC>ni^_Cliaiiiid(  Coatid.End)  ludMdual  queue; 
aodc:  DCS^Cootiol jGiaiiiid(  Ck»tndJ&id)  ladlvidual  queue; 
ac:  Satedke_Coii^_Clian^(  Amo.Cootrd.End)  indiTidiMl  queue; 

d:  Bvent_Log^Cliai^(  Event.Ead)  conuuMi  queue; 


■odnle  OROUND^CONTROLJTYPE  systemiMrocess;  {  Command  Functims  } 

IP  ~  ” 

bax:  Abstract_Bax_Clumnd(  Dala_Transfer_End)  individual  queue; 
ood:  DamjriaWer_Control_Chai^  Contol_End)  individual  queue; 
oct:  Tdemetry_,Contiol_Channd(  Control JEnd)  inAvidual  queue; 

Gcp:  Passw(»d_Contiol_Channd(  Contn>l_End)  individual  queue; 

od:  SW_Loed_C(Mitrdi_Channd(  Control_End)  Indiddual  queue; 

ocm:  Mailbox_Admin_Quuuiel(  Contiol_End)  indiddual  queue; 
ooe:  EPS_Ccmtrol_Channel(  Cmtrol.End)  in^viduai  queue; 
cocrni:  Comm_Control_Channd(  Control J^)  individual  queue; 
code:  DCS_Control_ciuuuid(  ContrdJEnd)  individual  queue; 
ac:  Satdlite_Control_Channel(  Ground_Control_End)  individual  queue; 

d:  Event_Log_Channel(  Event_End)  conunon  queue; 

Old; 

nwdufe  PRIMITIVE_SW_LOADER_TYPE  systemproccss;  {  PHTX  } 

ip 

oc:  SW_Load_Control_Channel(  LoadoJEnd)  individual  queue; 

bax:  Abstract JBax_Channel(  Datajrtansfer_End)  individual  queue; 
aid; 


module  TEL£METRY_GATHER_TYPE  qrstemiHUcess;  {  Automatic  Telemetry  Gathering  } 
Ip 

cc:  arrayp]  of  Telemetry_Control_Channel(  Telemetry_Gather_End) 

common  qpwue; 

ad:  A/D_Control_Channel(  Command_End)  individual  quaie; 

d:  EventJLog_Oiannd(  Event_&id)  common  queue; 

ts:  Teleiiwtry_Stmage_Channei(  Tdanetry_End)  individual  queue; 

end; 
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Module  A/D_DRIVERjrYPE  eyetanprocess;  {  Driva  for  Analog'Digital  Conv  HW  } 

ip  "  ’ 

ad:  A/D_Control_Channd(  A/D_Converter_Eiid)  individual  queue; 

end; 

UNdide  EVENT_.LCXKiER_TYFE  qntcnfNroceaB; 
ip  ~  ” 

d:  amqlfiMDtltnb  +  6]  of  Event_Los_Chaiiiid(  L(^_End)  common  queue; 

end; 

module  EPS_DRIVER_TYPE  qv^cn^Mveem; 

oc:  arrayp]  of  EPSjContrdjChannd(  EPS_Driver_End)  common  queue; 

end; 

module  COMMJDRIVERJTYPE  systemiarocess; 
ip  ”  ” 

oc:  aiTay[2]  d  Comin_Control_Channel(  Comm_Driver_End)  common  queue; 


module  DCS.DRIVERJTYPE  ^stemiHDcess; 
ip  ’  ” 

cc:  aiTay[2]  of  DCS_Contn>l_Chaimel(  DCS_Driv»r_End)  common  quaie; 

end; 


{  Module  Body  Definitions 

body  PRIMrnVE_AX25_BODY  for  PRIMrnVE_AX25_TYPE; 


external; 


} 


UOf  DATAJI1tANSFER_B(»>Y  for  DATAJTRANSFERJTYPE; 

{  AX.^  handler  -  uses  resources  of  BAX  } 

mail^ssld  » 0x01;  { SSID  of  diis  module  } 

maxcttents  »  any  uduv;  { the  max  number  of  'active  users  at  any  time  } 

tjimeout  »  any  udnr;  {  numba  of  seconds  f(»^  frame  time^t  timer.  } 

max Jinmes  *  0x07;  { frame  sliding-window  size.  } 

maxjries  »  any  udiar,  {  max  #  of  retries  fin  outgoing  frame  } 

padoetja^  «  max  jxiat  +  2;  {  max  size  of  FTLO  level  pocktt  } 


type 

Client_Num  « Q..maxcUents\ 

Qient  >  record 

callrign:  Callsign_Type; 

last_comm_time:  ulong; 

data_in_piogress:  boolean; 

end; 

Pac_Data  «  array(/Midtr/_i(rng/A]  of  uchar; 

Client_Array  «  arrayfm^/nib]  of  Client; 

Data_Reoord  «  record 
running_length:  uint; 
final Jength:  uint; 

data:  Pac^Data; 

end; 

Data.Array  =  array[mar/iid:5]  of  Data_Record; 


var 

data: 

length: 

in_dat: 

clients: 

d>: 

num_clients: 

new__userJockout: 

all^userjockout: 

packet: 

tiansmit_ok: 

i: 

b: 

1: 


Pac_Data; 

uint; 

Data^Array;  {  Array  of  incoming  data  on  each  link 
Client_Array; 

Control_Block; 

Clicnt_Num; 

boolean; 

boolean; 

Packet_Type; 

boolean; 

uchar;  {  goieral  purpose  loop  counter/  index 
Bit_'I^; 

Link_Type; 


sUte  NORMAL,  BUSY;  {  States  of  DATA  TRANSFER  BODY 

statcaet  EITHER  =  [NORMAL.BUSY]; 


} 

} 
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ftmctioii  CONCAT(  a,  b:  Pac_Data):  Pac_Data; 

primitive;  {  Concatenates  the  anay  ’b’  to  tte  end  of  array  } 

{  *a*,  and  returns  the  combined  array  of  uchars.  } 

Amctioii  PACKET.LENC  d:  Fdaia):  uint; 
bcflD 

PACKET  LEN  I  BTT  SHIFT(  kfi,  3,  INT(  C.BTT.ANIX  d[l),  OxEO))); 
PACKETlEN  ^CI^.LEN  +  INT(  dCO])  +  2; 

ead; 


procedure  FDX_PACKEr(  data;  Pac.Data;  var  packet:  Packet_Type); 

prlsiithe;  ~  { Takes  die  uchars  from  array  ’data'  and  places  } 

{  diem,  in  order,  into  the  record  structure  of  } 
{  ’pack^’.  } 

tiiirtaUM.  { DATA_TRANSFER_BODY  } 


to  NORMAL 
b^iii 

for  i : >■  0  to  maxUnks  do  clients[i].callsign  : «  ’none’; 
QAX_CLEAN_CB(  cb); 
di.my.call :«  pansatjcatt; 
d>.my_ssid :«  mailjsid; 
cb.tl  tjimeout, 
di.maxframe  :  =  max Jhmm\ 
cb.reby  :*  majries; 
cb.paclen max Jica\ 
num_clients 0; 
new_uaerJockout false; 
aU_user_lockDut : »  false; 
transmit_ok : » true; 
output  ^.qax_claim(  cb); 
end; 

trans 

from  EITHER  to  same 
iHieB  bax.qax_mput 

provided  in_q>.l^  »  qat^state  and  in_d>.l_state  =  qasjUsconnected 

begin 

if  in_d>.callsign  <  >  fqxijaU  then  num_clients  num_clients  - 1; 
clieiits[injcb.link].callsign  ’ncme’; 
ou^Rit  pc[in_cb.link].disoonnect; 

end; 
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tranmit  ok :» Ikbe; 
mOi 

firaai  filTHER  to  nme 
niM  oc{b].tiiiiSfiiittter 
provided  Mt  <rff 
bofjki 

tmundtjok :» tme; 
oidj 


I 


[ 


firon  ETTHER  to  sane 
wkoi  oc[b].chafigejpanuns 
bcgiB 

d> :»  out_d); 

cad; 

fkooi  EITHER  to  same 
trtMO  bax.qsx.ii^ut 
provided  «  qatjd 

bc^ 
cad; 

firoai  NORMAL  to  sanM 
Mms  oc[b].lockout 
provided  l_kind  »  new 
bcgfai 

iiew_userJockout  true; 
cad; 


{  No  action  required  -  discard  firame 


) 


Ikon  NORMAL  to  same 
odMa  oc[b].uiilock 
provided  Inland  »  new 
b^ia 

new_user_lockout :»  false; 

cad; 
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tinmma3Rt»mam 
iPkM  pe(l].RapoQiejMcloet 
pfwrMed  truuimt.ok 

Uffm 

:«•  PACXET_LEN(  re^xmae)  +  2; 
i  :■»  0; 

irtAei  <  kfigtii  do  bcfiB 

oiifle  i  <  oiitjd>.iMclen  and  i  <  length  do  begin 
dataO] :»  reaponacD]; 
i:-i  +  1; 

•ad; 

OB^^  bax.<iaxjlata(  1,  out_d>,  data,  i); 

kitgth  : »  length  •  i; 

i:-0; 

end; 


firam  NORMAL  to  same 
idien  bax.qax_ii^t 

provided  in_d>.kind  «  gatjstate  and  in_d>.l_state  =  qasjMimect _pend 

b^in 

tf  in_d>.hisjcall  «  rqajcaU  th«a 

dientsnn_cb.link].callsign :»  npsjxUl; 
clientsOnjd>.link].laat_poniin_tinie  :=  GETjnME( ); 

OH^ut  bax.qaxjcon_acpt; 
output  pc[in_d>.linkl.connection(  npsjcall); 
utd; 
dse 

if  num_clients  <  maxcUems  and  not  new_usa^_lockout  then  begin 
num_clients  nuin_clients  +  1; 
clienls[mjcb.link].caUsign  :«  injcb.hisjcall; 
cliaits[ui_d).link].last_coinin_tiine  :*  GET_TIME( ); 
ouQwt  l^,qaxjcon_aq>t; 
output  pc[in_^.link].CQnnection(  in_cb.his_call); 

Old; 

dse  output  bax.qax_con_rg; 

end; 
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tamdOfALtoBUSY 
i4mm  €e{b].loelBoiit 
prafiMl  kind  *00 
btfin 

an.ttser.lodkottt  :*  true; 
new_ttser_lockDiit  :*  true; 
fori  *  1  tomaxUnks  do 

if  clknts[i].callsign  <  >  ’none’  end  dkntsTO.callsign  <  >  nps_adl  thoi 
output  qaxjHisyO); 

end; 

flrani  BUSY  to  NdtMAL 
uliai  oc[b].iuilock 
prorided  1  Jdnd  *  aU 
bc^ 

aU_userJockout  :*  false; 
for  i  *  1  to  inax_liiiks  do 

if  clients[i].callugn  <  >  ’ncme*  and  cliaits[i].callsign  <  >  npsjcall  then 
output  qax_unbusy(i); 

end; 

fhnn  BUSY  to  same 

i^en  bax.qu_input 

prorided  in_^.kind  *  qat^suue  and 

in_d>.l_state  *  qasjMnnect jpend  and 
in_d>.his_call  =  npsjxiU 

begin 

dients{in_d>.link].callsign  :=  nps_call; 
clients[in_d).link].last_comm_time  :=  GET_T1ME( ); 
output  bax.qax_o(m_aq>t; 
output  pc[in_^.lin]0.connecti<m(  nps_caU)', 

Old; 
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fiPM  ETTHER  to  SMiie 
whm  box.qax.iiiput 
ppoHdod  iii_d>.ldiid  «  qatJUua 


i  injcb.link; 

clients(^.Iastjoofnm_.tiiiie :«  GETjnME( ); 
if  cliettts[i].<^.inj)iQSiess  then  begin 
date :» inj£a(i].date; 

Icngdi :»  ^_dat[i].nifiiiing^lengtfi; 
m_dat[q.data  :«  CONCAT(  data[0.. length],  idata); 

ICQgdi length  +  datal; 
if  kngd!  <  in_dat0].iinal_lengdi  dien 
uijlat(i].niniiifig_length  :«  length; 
elie  begin 

clients[i].data_inj)rograss  false; 

FILL_PACKET(  in_dat[i].data,  packet); 

output  pc[i].coinin^_packM(  packet,  in_dat[i].finalJength-2); 

end; 

dee  begin 

length  PACKET.LENC  idata); 
if  datal  <  length  dus  begin 

clients[i].data_in_progress  : «  true; 
in_dat[i].data :»  idata; 
injdat(i].ninning_length  :=  data!; 
in_dat[i].fiiialjength  :=  length; 
dee  begin 

FILL^PACKETC  idata,  packet); 

output  pc[in_cb.link].commsmd_packet(  packet,  length  •  2); 
end; 
end; 

Old; 


{  of  Data_Transfa’_Body  } 
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btdISF  PACKETJTRANSFER.BODY  for  PACKET.TRANSFER^TYPE; 


dotn 

tkaajmd 

loginjtsp 

iq>load_cmd 

id 

ul_errorjesp 

idjidtjtsp 

uijukjtsp 

doimloadjcnid 

dljgrrorjtsp 

dljtbortedjtsp 

dl jximple^jtsp 

dljukjynd 

dljukjmd 

dirjhortjynd 

dirjongjatid 

sekajand 

selectjresp 

deljand 


deljresp 


nojactivejist 
active  list 


»0x00 
»Qx01 
-  0x02 
»  0x03 

*  0x04 
»  OxOS 
»  0x06 
»  0x07 
»  0x08 
»  0x09 
■s  OxOA 
»  OxOB 
»  OxOC 

*  OxOD 
=  OxOE 
=  OxOF 
=  0x10 
=  0x11 
=  OxlE 


=  OxlF 


» 


=  0x00; 
=  0x08; 


{  CoMtonts  for  PACKET.TRANSFER^BODY  } 
{ Pocket  Types  } 


{  There  is  no  difference  between  the  short  and  long  } 
{  dir  formats-  both  s«id  complete  headers.  } 


{  Delete  a  file...  not  provided  for  in  FTLO.  } 

{  For  del^cmd,  the  following  packet  fields  apply:  } 

{  length_^  :  =  0x04;  hi :  =  OxlE;  } 

{  info[0..3]  :*  mail_number:  ulong.  j 

{  Not  provided  for  in  FTLO.  } 

{  ThefoUowing  packet  fields  apply:  } 

{  l«ight_lsb  :=  0x01;  hi  :=  OxlF;  } 

{  info[0] :  =  error_code:  uchar.  } 

{  These  are  the  FTLO  login  flags,  assuming  } 

{  PACSET  File  Headers  are  Not  used  ) 


var  p: 

clioit_callsign: 

selectionjtctive: 

or^code: 

currentjil_mail: 

current_ul_ofPset: 

current_dl_mail: 

currait_dl_offset: 

datajength: 

sele^: 


PacketJType; 

Callsign_Type; 

uchar; 

uchar; 

ulong;  {  mail_number  of  file  curraitly  being  uploaded.  } 

ulong;  {  Numbo^  of  next  byte  to  be  uploaded  in  current  file.} 

ulong;  {  mail_number  of  fUe  currently  being  downloaded.  } 

>ii<mg;  {  Num  of  n^t  byte  to  be  downloaded  in  current  file.} 

Pdat_Len; 

Pdata;  { Raw  select  instruction.  } 
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{  States  of  PACKET  TRANSFER  BODY  } 

stote  UL/DL  UNINTT,  WATT  MAILBOX,  UL/DL  CMD  WATT,  UL  DATA  RX, 
UL_ABORT,  DL_FILE_bATA; 

statcset  ANY  »  [  UL/DL  UNINTT,  WATT  MADJBOX,  UL/DL  CMD  WATT, 
UL^ABORT,  DL_FILEJ>ATA]; 


{  F^mction  Declaratioiis  for  } 

{  PACKET_TRANSFER_BODY  } 

ftinctioD  CURRENT_COMMAND(  packet:  Pack^_Type):  uint; 

bcglii 

CURRENT.COMMAND  :=  C_BTr_AND(  packet.hl,  Oxlf); 
end; 

{  Procure  declarations  for  } 

{  PACKET_TRANSFER_BODY  } 

procedure  FORMAT_LOGIN_RESP(  login_flag:  uchar;  var  packet:  Packet_Type); 

▼ar  login_time:  ulong; 

b^in 

packet.lengthjsb  :=  OxOS;  {  S  byte  information  field  } 

packet.hl  :^login_resp;  { loginjesp  Packet  Type  } 

packet.info[0..3]  ;=  GBr_TIME( ); 
packet.info[4]  :=  login^flag; 

end; 


procedure  FORMAT_UPLOAD_GO_RESP(  file^no,  offset:  ulong;  var  packet: 

Packet_Type); 

begin 

packet.length  Isb  :  =  0x08;  {  8  byte  information  field  } 

packet.hl :  *=  UPLOAD_GO_RESP; 
packet.info[0..4]  :=  file_no; 
packet.info[S..7]  :=  offset; 
end; 

procedure  FORMAT_NI_RESP(  tag:  uchar;  var  packet:  Packet_Type); 

begin 

packet.lragth  Jsb  :  =  0x00;  {  No  information  } 

packet.hl :  =  tag; 
md; 
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POUiiAT_UL.ERRORJRESP(  enon  udiar;  var  padcet*  FKket.iype); 


padBrt,kngtti_l«b :«  0x01; 
pidBeLhi :  ■*  Idjanrjt^; 
padcet.iiifoltQ  :*  error; 

end; 

pnoeednre  FORMAT_UL_NAK_RESP(  errcnr:  uchar;  nur  packet:  PackBt_Type); 
bcgfaa 

packet  lenstt_lab :»  0x01; 
packethl  •.•Idjtdkjesp: 
padGetinfolO]  :•  error; 
end; 

procedure  FORMAT_SELECT_RESP(  num:  uint;  var  pactet:  Packct_Type); 


packetJengthJsb  0x02; 
packeC.hl seleajesp\ 
packet.info[0..1]  num; 
end; 

procedure  FORMAT_DL.ERROR_RESP(  error:  uchar;  var  packet:  Packet^Type); 
h^n 

packet.leQgth_lsb  :=  0x01; 
packet.hl  :^"dljtrrorjesp\ 
packet.info[0] :«  error; 
end; 

fwocedure  FORMAT_pEL_RESP(  error:  uchar;  var  packet:  Packet^Type); 

be^ 

packet.lengthjsb  :=  0x01; 
pecket.hl  deljresp', 
packi^.info[0] :  =  error; 

Old; 


I 
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procctee  FORMAT_DATA(  ten:  Pdat.Len;  dat:  pdata;  var  pacloM:  Packet_Type); 
var  liighj>yte:  udiar; 
msb:  uint; 

bcfln 

packet.teiigth  Isb  GET  LSB(  ten); 
liiih  tiyte  GET  MSB(  ten); 
mA  :«  I  BIT  SH^(  S.  INT(  high  byte)); 
pK^.hl :»  OET.LSBCmsb); 

INicltet.info(0..ten-T] :»  datCOwlen'l]; 
end; 

« 

inktaiiM.  {  PACKET.TRANSFER  BODY  } 

to  UL/DL.UNINIT 

be^ 

end; 


tnms  {TransiUon  Fart  of  PACKET  TRANSFER.BODY) 

firom  ANY  to  UL/DL_UNINIT 
alien  pc.disconnect 

begin  {  Link  has  been  terminated  by  client  or  satellite.  } 

md;  {  No  action  required.  } 

firoin  UL/DL.UNINIT  to  WAir_MAILBOX 

irfien  pc.Gonnection 

bmin 

cltent_callsign  : »  callsign; 
output  mc.active_sl_ieq(  callsign); 
end; 

from  WATT^MAILBOX  to  UL/DL_CMD_WAIT 
adien  nic.active_sl_resp 

begin 

if  si  then  sdection_active  :  =  active  Jist; 
ebe  selection  active  no  active  list\ 

FORMAT_L6GIN_RESP(lclection_active,  p); 
output  pc.ieqxxisej»ckrt(  p); 
end; 

from  UL/DL_CMD_WAIT  to  same  {  Default  condition  for  unexpected  packet  or  } 
idioi  odiers  {  format.  } 

b(^ 

FORMAT_UL_ERROR_RESP(  erJUJomedjmd,  p); 
output  pc.re^nsej}acket(  p); 

»d; 
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Wm  uUBLjB»e>j9fAir  t*  wait.mailbox 


pravIMI  CIJIBENrr_.C(MifMAND(  oommand)  >  uploadjmd 

aalpat  iiic.iBail_iHiiii_req(  dient^callsign,  cominaiid[2..5],  aMninand[6..9]); 


from  WAIT.MAILBOX  to  UL/DL.CMD.W  ATT 
akcB  iiic.iii^_nuin_ie9 
proridod  enor.oode  <  >  nojerror 
iMgill 

FORMAT_UL.ERROR.RESP(  cnor.codc,  p); 
ou^Nit  pc.reqxmsejMcl^  p); 
end; 

from  WAIT.MAILBOX  to  UL.DATA.RX 
whoi  mc.mail.num.re^ 
proYided  enor.code  »  nojerror 
bqiin 

cunent.ul.mail mail.number; 
cunent.ul.offset offs^; 

FORMAT.UPLOAD.GO.RESP(  mail.number,  offset,  p  ); 
output  pc.iespcmsejpacketf  p); 
md; 

from  UL.DATA.RX  to  UL/DL.UNINTT 

^iHien  pc.disccmn^  {  data  link  terminated  by  clioit  or  satellite. 

b^in 

ou^Nit  roc.mail.close.reqC  currait.ul.mail,  curroit.ul.offset,  false); 

Old; 


from  UL.DATA.RX  to  UL/DL.CMD.WATT 

wben  oChen  {  Default  condition  for  unexpected  packet  or 

{  format. 

output  mc.mail.close  ieq(  currmt.ul.mail,  current.ul.offset,  false); 
F0RMAT.UL.ERR0R.RESP(  erjnjomed_cmd,  p); 
outpirt  pc.iesponsej»ci^(  p); 


Aram  UL.DATA.RX  to  WATT.MAE^X 
trtwn  fc.ciNiiiiiandjMidcBt 

provided  CURRENT.COMMAND(  coflunand)  »  datajend 

bc^ 

o^ot  iiic.iiiail_dose_ieq(  cuntnt_ul_inail,  cuneiit_ul_offset,  true); 

end; 

fhMB  WAIT.MAILBOX  to  UL/DL.CMD_WAir 
when  mc.mailjclosejre^ 

begin 

if  enorjoode  «  no_error  flien  FORMAT_NI_RESP(  uijickjtsp,  p); 
dM  FC»MAT_UL_NAK_RESP(  enorjcode,  p); 
on^Nit  pc.feqx)iisej»ck^  p); 

Old; 

from  UL_DATA_RX  to  WATT^MAILBOX 
vriim  pc.command jacket 

provided  CU]RRENT_COMMAND(  command)  =  data 
data_Iength :»  da^; 

ou^Nit  mc.mailjrecv(  cunent_ul_mail,  cumnt_ulj>ffset,  latajoigth,  command.info); 
eid; 

from  WATT^^MAILBOX  to  XJL^DATA.RX 
when  mc.ttudljtecvjtesp 
fvovided  ertor_code  =  nojerror 
begin 

current_ul_offs^  :  =  current_ul_offset  +  datajength; 

Old; 

from  WAIT_MAILBOX  to  UL_ABORT 
whro  mc.mail_iecv_Tesp 
prodded  oior^code  <  >  nojerror 
begin 

FORMAT_UL_NAK_RESP(  error_code,  p); 
output  pc.iesponsejacket(  p); 
end; 

from  XJL_ABORT  to  UL/DL_CMD_WAIT 

vdien  otbm  { De&uk  condition  for  unexpected  packet  or  } 

be;^  {  format.  } 

FORMAT_UL_ERROR_RESP(  erjtt Jbrmedjand,  p); 
output  pc.ieqxxisejHick^C  p); 

end; 


m  mMjmwAiT 


pMlili  Cim^NT.CXIiOfANDC  oommaiid)  «  dmjmd 

{  No  a^km  lequiied 


fiPMiUL  ABORTto 


pttwidtd  ClJRRENTjCX3MMANlXooiiiina^  -  data 

begin  {  No  action  required  } 

endf 


Aroin  XIL/DL.CMD JV  AIT  to  WATT.MAILBOX 
idwn  |tt.ooinmaiid_packet 

provided  CURRENT_COMMAND(  command)  =  deljmd 
b^fai 

ontpot  mc.mail_dd_req(  dient^callsign,  command.info[0..3]); 

end; 

fhm  WATT^MAILBOX  to  UL/DL_CMD_WAIT 

iHien  mc.inail_dd_resp 

begin 

FORMAT_DEL_RESP(  cnor.code,  p); 
output  pc.responsej»ckiet(  p); 

end; 

fhmi  UL/DL_CMD_WAIT  to  WAIT_MAILBOX 
irtien  pc.o(mimand_pack^ 

INTOvided  CURRENT_COMMAND(command)  =  seleajmd 

begin 

adect :»  o(Mnmand.info[0..datal-l]; 
oii^Nit  roc.msdect_req(  client_callsign,  select); 

end; 


[ 
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WATT.MAILBOX  to  UUDL.CMD.W ATT 
iiic.aisdectjmp 


if  error joode  «*  mjenor  thco  bc^ 
ideetioQ  active :«  octiro  fisr; 
FORMAT.SELECT.RES^  num.ad,  p); 
eoNi} 


adoction  active  :■>  no  Active  tisr; 

FORMAT.DL.ERROR.KES^  error.code.  p); 

wd; 

output  pc.reeponaejMckBtC  p); 
cud; 

from  XJL/DL.CMD.WAIT  to  WAIT_MAILBOX 
when  pc.aMnmandJpadcet 

provided  (  CURRENT_COMMAND(coininand)  =  dir_shon_and 
or  CURRENT_COMMAND(  comma^)  »  ^rjongjcmd) 
and  ( 

(oominaiid.info(0..3]  <  >  QxOOOOOOOO  and  cominand.info[0..3]  <  > 

OxFFFFFFFF) 

or  selection  jictive  »  active  Jist) 


if  ooniinand.info[0..3]  »  0x00000000  or  cominand.info[0..3]  =  OxFFFFFFFF  then 
output  inc.dir_ieq(  client jcallsign,  0x00000000); 


end; 


output  fnc.dir_itq(  client_callsign,  cominand.info[0..3]); 


from  UL/DL_CMD_WA1T  to  same 


uhcn  pc.oonunandj»cket 
provided  (  CURRENT_COMMAND(command)  « 
or  CURRENT_COMMAND(  command) 

and  not  ( 

(oommand.info(0..3]  <  >  0x( 


I.M  I  l.l » I 


'  dirjihortjofid 
=»  dirjongjmd) 

and  command.info[0..3]  <  > 

OxFFFFFFFF) 


sdectkm  active  ^  active  list ) 

bcfia 

FORMATJDL_ERROR_RESP(  erjelectUmjtmpty,  p); 
output  pc.feqx)nsej[)ad^  p); 
end; 
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CmOKEHTJCOUMANDi  oonmaiid)  «  ajidcjmd 

{ AO  action  lequM 


} 


Ami  WArr.MAOAOX  to  ULyDL.CMD.WATT 
otai  iDc.diflKlo(y 

biflo  { Eodi  FQe  Heodsr  onist  » <  200  bytes  } 

If  oojd  ttMO  idection_ACtive  tiojKtiveJist; 

If  loT  <  >  0  tbea  bcita 

FCMtMAT_pATA(  len,  dir,  p)  {  Assumes  10  file  headers/DataPacket  } 

outpot  pc.ie4KMsej>aclDet(  p); 

FC»MAT_NI.RESP(  datajend,  p); 
ootpnl  pc.ieiponsejiaclcet(  p); 

cad; 

die  begio 

FORMAT_DL_ERROR_RESP(  dir[0],  p) 
ootpiit  pc.reqxNisejwci^  p); 

cad; 

cad; 


firoB  UL/DL_CMDJ¥AIT  to  same 
whea  pc.oommand 

prarlded  CURRENT_COMMAND(  command)  «  domioadjmd  and  ( 
(ooaunand.info[0..3]  >  0x00000000  or  commaiid.info[0.. 3] 
and  sdectionjetive  *  nojtctivejist) 

bcgfai 

FCHtMAT_DL_ERRC)R_RESP(  erjel^xionjempty,  p); 
ootpot  pc.ieqxmse jacket  p); 


OxFFFFFFFF) 


Irani  UL/DL.CMD_WArr  to  DL_FILE_DATA 
idMB  pc.oommand 

provided  CURRENT_COMMAND(  command)  »  damioadjemd  and  ( 

(oommand.info^..3]  <  >  0x00000000  and  command.info[0.. 3]  <  > 

OxFFFFFFFF) 

or  selection_active  »  active Jist) 


HI  1 1 1 1 1 


cttncntjdljifiset oonuiiand.tnfo[4..7]; 
cnnentjll^mail :«  aNnmand.infi)p)..3]; 

If  current jdl.mail ;  ■  OxFFFFFFFF  thra  cunent_dl_mail :  *  0x< 
oatpnt  mc.i^.req(  cUent_caUsign,  current_dl_miul7  cunient_dl_offset); 
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firwi  »L.F1LB_DATA  to  ULyDL.CMD.W ATT 
irtMB  mc.nail.ie9 

praiMid  toagth  »  0  aad  mailEOH  <  >  0  { Eixor  flag  from  mailbox  } 

if  BO  al  ttWB  idactioii  active :«  no  active  list; 

FOldMfATJDL.EItRdt.RESP(  maiip)].  p)T 
pc.ie9CMiaejwclDei(  p); 

Md; 


freai  1H.JPILE.DATA  to  aanie 
bImb  Bic.iBail.fe9 

preoidad  len^  <  >  0  or  ( iBaiUO]  >  0  and  tengdi  «  0) 
begfai 

if  no.al  tten  adectkm.active  :«  nojictivejist; 
if  lofth  «  Ottenb^ln 

F(»MAT.NI.RESP(  datajmd,  p); 
o^pnt  pc.iespofuejncketTp); 

CBd; 


FORMAT.DATA(  length,  nuul,  p); 
output  pc.ie9onaejpacket(  p); 
cunent.dljrftet cunent.dl.ofrset  +  length; 
tf  cuitent.dl.inail  «  0x00000000  then  cunent.dl.maii mail.number; 
mc.i^.ieqC  client.call^,  cunent.df  n^,  cunent.dToffset); 

end; 


flroai  DL.FILE.DATA  to  XJL/DL.CMD.WATT 
wim  pc.ooinnu^j)ackirt 

proviM  CURRENT  COMMAND(  command)  »  dljack  cmd 

begin 

FORMAT.Nl_PACKET(  dl_con^Utedjtsp,  p); 

OB^ot  pc.ie9onsej)acl^  p); 

ou9fd  mc.dljick(  client.ca^gn,  cunent.dl.maii); 

«d; 


finMB  DL.FILE.DATA  to  UL/DL.CMD.WATT 
iHwn  pc.oomiiu^ jacket 

pcoviM  CURRENT.COMMAND(  command)  »  DL.NAK.DMD 
bt^in  ~ 

FORMAT.NI.PACKET(  dljibortedjesp,  p); 
output  pc.ie9onsej)Bck^  p); 
cad; 
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wUft  pe.tapoim_pteket(  p); 

md; 

mdf  { of  PACKET.TRANSFER.BODY  } 
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body  MAILBOX_CONTROL_BODY  for  MAILBOX_CONTROL_TYPE; 


const 


eof 

=  . 

{  End  Of  File  marker  used  by  qmating  system. 

} 

null 

{  Hie  null  pointer.  A  pointer  which  is  null  points  } 

{  to  nothing,  and  marks  the  end  of  a  linked  list. 

} 

anpty^string 

{  An  empty  string  as  defined  by  tolerating  system. 

} 

maiWM JUU 

»  any  uint;  {  Parameter  for  FORMAT_EVENT_REPORT 

} 

grab 

=  0x01; 

{  A  parameter  needed  by  ’qax_claim’. 

} 

maiIbox_ssid 

=  0x01; 

mail Jlag 

»  OxbbSS 

> 

min JileJength 

s  0x00000029;  {  Mm  of  41  bytes  m  the  mitialized  mail  me.  | 

maxjext 

«  0x03E} 

{  Higest  mail  name  extension  =  999  dec. 

} 

drfault_stayjime 

ss  any  ulong;  {  Default  mail  life,  in  seconds  from  upload. 

} 

mantypes 

s  any  uchar;  {  Number  of  different  file  types  allowed. 

} 

numcomps 

s  any  uchar;  {  Number  of  different  file  compression 

} 

{  methods  allowed. 

} 

{  Iton  numbers  for  fields  in  the  PANSAT  file 

> 

{  header,  for  use  in  ^select*  statements. 

} 

fl 

=  0x00; 

{ flag 

} 

mn 

=  0x02; 

{  mail_number 

} 

ml 

=  0x06; 

{  lengdi 

} 

ft 

=  OxOA; 

{ file^type 

} 

a 

=  OxOB; 

{  compression_type 

} 

bo 

=  OxOC; 

{ body_offset 

} 

dc 

=  OxOE; 

{  download^count 

} 

sc 

=  OxOF; 

{  source 

} 

pr 

=  0x15; 

{  priority 

} 

ut 

=  0x16; 

{  upioad_time 

} 

et 

=  OxlA; 

{  expire_time 

} 

na 

=  OxlE; 

{  mail_name 

} 

ex 

=  0x26; 

{  mailjextension 

} 

nd 

=  0x29; 

{  num_destinations 

} 

ds 

=  0x2A; 

{  destination  callsigns  or  paths 

} 

ti 

=  0x54; 

{ title 

} 

kw 

=  0x74; 

{  keywords 

} 

panjel 

=  OxFF; 

{Relational  operators  in  *select_struct’ 

> 

equaljru 

=  0x00; 

{  equal  to  an  unsigned  1,2  or  4  byte  integer 

} 

equal_str 

=  0x03; 

{  equal  to  a  string 

} 

great Jnt 

=  0x10; 

{  grater  than  an  unsigned  1,  2  or  4  byte  integer 

} 

lessjrtt 

=  0x20; 

{  less  than  an  unsigned  1,  2  or  4  byte  integer 

} 

notjequjm 

=  0x30; 

{  not  equal  to  an  unsigned  1 ,  2  or  4  byte  integer 

} 

notjsqujtr 

=  0x33; 

{  not  equal  to  a  string 

} 
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frjcgvjbt 

-0x40; 

{  pKdxx  than  or  oqod  to  an  unsigned  integer 

) 

JtjmaJm 

-QxSO; 

{ less  than  or  equal  to  an  imsigned  integer 

) 

1  and 

mm 

«Qx80; 

{ togicd  *and* 

} 

lj» 

-QxEO; 

{ logical  *or' 

} 

tm 

meJEaa 


Ext_Typc  ■ 

Mail_Ajnay  « 

SdertJList  » 

num^sd:  Num^Mail; 
ad:  Mail^Anay; 

end; 


{ types  for  MAILBOX_CONTROL_BODY. 
0..max_ext; 

•rrtyp]  of  udiar; 

amy[maxjnaU\  of  ulong;  {  Array  of  inail_numbers 
record 


SouroeJRecord 

source_nuin: 

call: 

sdected: 

next^mail: 

next^dir: 

next^ext: 

num_,act: 

next^num: 

next^call: 

end; 


«  record 
uint; 

Callsignjrype; 

Sdect_Lht; 

Nuin_Mail; 

Num  Mail; 

FUc.Ext; 

uchar; 

'*‘Souice_Record;  {  Pointer  to  a  source  record. 
'"Sou]ce_Recotd; 


Letter^Anay 

File_pesig_Anay 

C<Mnpression_Anay 

S_Name 

FUe_0<ter 


»=  arraypd]  of  ‘*‘Souicc_Record; 
=  array  [num/yper]  ot  uchar; 
s  arniy[mtfnco^5]  oi  uchar; 

«  array[8]  uchar; 

=  ( date,  name); 


} 

} 


} 


var 

done: 

fildype: 

conqKype: 

next_aouice_nuni: 

nad: 

file_name: 

rfik,  tfile: 

first_let: 

mail.head: 

teiiq>l,  temp2: 

iiiail_num: 

ext: 


boolean; 

Filc_Desig__AiTay; 

Conipression_Anay; 

uint; 

Num_Mail; 

NameJType; 

""FileJType; 

Ldter,Array; 

‘*‘Sour^JRecord; 

‘*‘Source_Record; 

ulong; 

Ext_Type; 


133 


time: 

ulong; 

Unk: 

Unkjrype; 

fUe.kngth: 

uloQg; 

filejofbet: 

ulong; 

botty.olCMt: 

uint; 

fiksjenor 

udiir, 

id^: 

Sdect.Lut; 

numjdeit: 

uchar, 

cs: 

Callsign JIVP^; 

i: 

uint;  { loop  coi 

j»k: 

uchar, 

tiirjdat: 

Pdata; 

iqi^ 

Event  Rqxirt  Type; 

order: 

Filc_Qitier; 

sname: 

S_Name; 

d_file: 

Flic_Type; 

state  WAIT; 

ftuictioB  STRING_COMPASE(  strl,  sd^:  ''Byte_Anay):  bot^ean; 

priodtive;  {  Compares  ’strl*  to  'sti2’  and  returns  true  if  they  } 

{  are  die  same,  othowise  returns  false.  } 

Amction  STRING_FIND(  strl,  sti2:  ‘^Byte.Array):  boolean; 

primitive;  {  Looks  to  see  if  ’strl*  is  contained  anywhere  within  } 

{  ’str2’.  Returns  true  if  it  is,  and  false  if  its  not.  } 

ftmctkm  GEr_LENGTH(  file_naine:  NartwJType):  ulong; 

primitive;  {  Returns  the  length  of  the  stored  file  ’file^name*  } 


function  GEr_LSI(  number:  ulong):  uint; 

IHimitive;  {  Takes  a  4  byte  number  and  returns  the  least  } 

{  si^ficant  2  bytes.  } 

ftinction  GEr_MSI(  numbo::  ultmg):  uint; 

primitive;  {  Takes  a  4  byte  number  and  returns  the  most  } 

{  ngnificant  2  bytes.  } 

Amction  MEM_SPACE( ):  ulong; 

prfaidtive;  {  Returns  the  number  of  bytes  of  available  } 

{  ^»oe  in  mail  box  memory.  } 
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ftiadlM  S!ZEjOF(  type.iadkator):  uint; 

prhniliv^  {  Takes  as  an  aigument  any  type  aixl  r^ums  the  } 

{  numbo’  of  bytes  needed  to  ^le  a  variable  of  } 

{  that  type.  } 

ftmctioB  ALLOCATE(  size:  uint ):  p(diiter_type; 

primitive;  {  Allocates  a  block  of  dynamic  memory.  The  } 

{  number  of  bytes  in  the  block  is  indicated  by  } 

{  'size*.  The  function  returns  a  pointer  to  the  } 

{  newly  allocated  block.  } 


ftinctioo  EXISTS(  file_name:  Name_Type):  boolean; 

primitive;  {  Takes  a  complete  DOS  file  name  as  an  argument  } 

{  and  returns  } 

{  true  if  an  active  file  by  that  name  currently  exist^ 

{  in  the  mass  storage  memory,  otherwise  returns  } 

{  false.  } 


fimction  GHT_FIRST_FILE(  order:  File_Onter;  fh:  S_Name):  Name_Type; 
primitive;  {  Returns  the  name  of  the  first  active  (not  deleted)  } 

{  mail  file  in  the  mass  storage  memory.  "First"  is  } 
{  defined  as  the  oldest  file  ( the  one  with  the  } 
{  earliest  creation  date)  if  ’order’  is  date.  If  ’order) 
{  is  name  then  ’fh’  is  a  DOS  file  name  minus  the  } 
{  extension,  and  the  file  name  returned  is  the  one  } 
{  with  the  "&st”  alpha-numeric  extension  } 

{  associated  with  the  ’fn’  given.  If  no  file  matches) 
{  the  critria  given,  then  enipty_string  is  returned.  } 


ftmctlon  GET_NEXT_FILE(  wder:  File_Order;  prcv_file:  Name_Type  ):  Name_Type; 

INrlmltive;  {  Starting  at  ’prev_file’,  searches  the  mail  area  of  } 

{  mass  storage  memory  for  the  next  active  file.  If  ) 
{  ’order’  is  date,  the  next  file  is  the  one  with  the  } 
{  next  later  creation  date.  If  ’order’  is  name  then  } 
{  the  next  file  is  the  one  with  the  same  leading  8  ) 
{  characters  and  the  next  higher  alpha-numeric  ) 
{  extension.  This  function  returns  the  complete  file) 
{  name,  if  found  and  returns  empty_string  if  no  file) 
{  matching  the  criteria  exists.  } 
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ftmctioo  OPEN_FILE(  fUe_naine:  NanwJType):  *File_Type; 

primitive;  {  Opens  the  file  designs^  by  ’file^name’  for  } 

{  reading  or  writing.  Returns  a  pointer  to  die  } 
{  b^inning  of  the  file.  If  the  file  does  not  already} 
{  exist,  it  will  be  created,  and  will  be  empty  excqit} 
{  for  an  eof  mark.  } 

function  READ_FILE(  qty,  size:  uint;  var  filej>tr:  ‘^File_’I>pe):  Byte_Array; 
primitive;  {  Reads  blocks  of  bytes  from  memory,  starting  at  the} 

{  location  indicated  by  ’filejptr’.  Tito  number  of  } 
{  blocks  is  determined  by  ’qty’  and  the  number  of  } 
{  bytes  in  each  block  is  determined  by  ’size’.  The  } 
{  bytes  are  placed  in  the  ^re_allocat^)  variable  or} 


{  buffer  space  designated  on  the  left  side  of  an  } 
{  assignment  statement  of  which  this  function  call  } 
{  is  the  right  side.  After  the  read,  ’file_ptr’  will  } 
{  point  to  the  byte  following  the  last  byte  read.  } 

procedure  WRITE_FILE(  v:  Byte_Array;  num_bytes:  uint;  var  file_ptr:  '’‘File_Type); 
primitive;  { Writes  the  number  of  bytes  indicated  by  } 

{  ’num_bytes’  to  memory  starting  at  the  location  } 
{  indicated  by  ’filejitr’.  The  bytes  are  copied  } 


{  beginning  from  the  first  byte  of  ’v’.  ’v’  can  be  a} 
{  variable,  buffer  name  or  file  pointer.  After  the  } 
{  write,  ’filejitr’  will  point  to  the  byte  following  } 
{  the  last  byte  written.  If  there  is  already  data  in  } 
{  the  file  at  the  position  indicated  by  ’filejitr*,  that} 
{  data  will  be  overwritten:  If  writing  to  the  end  of} 
{  a  file,  the  marker  will  be  moved  to  indicate  } 
{  the  new  end  of  the  file.  } 

procedure  FILE_SEEK(  num_bytes:  int;  var  filejptr:  ■*‘File_Type); 

primitive;  {  Moves  the  file  pointer  ’filejitr’  the  number  of  } 

{  bytes  designated  by  ’num_bytes’,  without  reading} 

procedure  FILE_SEEK_SET(  num_bytes:  int;  var  filejitr:  '’'File_Type); 

primitive;  {  Same  as  ’FILE_SEEK’,  except  that  ’filejitr’  is  firs} 


{  moved  to  the  beginning  of  the  file,  and  then  } 

{  advanced  the  number  of  bytes  indicated  by  } 

{  ’numjiytes’.  } 

procedure  DEL£TE_FILE(  fiile_name:  Name_Type); 

primitive;  { Deletes  the  file  designated  by  ’file_name’  } 
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} 


pieiiwt  CLOSEJFa£(  filejMine:  NmJType); 

{  CkMes  the  fUe  designated  by  *file_naine’ 

proeedore  FREE(var  node_ptn  poiiderj^rpe); 

pitalttve;  {  D^ocates  a  dynamic  memory  node,  and  makes  } 

{  die  pmntfa^  miu.  } 
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procedure  DBCREMENT_MSG(  tcali:  Callsipn^Type;  rer  in_head:  '^Souioe.Reocmi; 

letter:  Li^_Arrey); 

ear  tempi,  teiiq>2,  head,  deljiode:  ‘^Souice.Reccml; 
index:  udiar; 

iMCiB 

ddjmde :«  nuff; 
indin  :»  tcall[0]  -  0x41; 
head  :*  ktteiOndex]; 
if  head  <  >  md/dirab^jn 

if  head  ->  call  »  tcall  thoi  begin 

head  ->  num_act :»  head  ->  numjict  - 1; 

if  head  ->  num_act  <  ^  0  and  head->selected.num_sel  <  »  0  tboi  begin 
del_node :«  head; 
ktt^index] :»  h^  ->  next_call; 
end; 
end; 

dseb^in 

temp2  head; 
tempi  :«  head  ->  next_call; 
while  tempi  <  >  null  do  b^ln 
if  tempi  >>  call  s:  tcall  then  b^in 

tmnpl  ->  num_act  :=  tempi  ->  num^act  >  1; 

if  tempi  ->  num_act  <  =  0  and  temi^->selected.num_sel  <  =  0 

then  b^in 

del_node :-  tempi; 

temp2  ->  nextj^  :=  tempi  ->  next^call; 
and; 
end; 

dseb^in 

temp2  :-  tempi; 
tempi  :s  tempi  ->  next_call; 
end; 
end; 
end; 

if  dd_node  <  >  null  then  begin 
h^  :  =  m_head; 
if  head  «  dd  jiode  then  b^in 
m  head  :»  head  ->  next  num; 

FREE(  deI_node); 
end; 

dee  begin 

temp2  :«  head; 

tempi  :»  head  ->  next_num; 

iHiile  tempi  <  >  null  do  begin 
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f  -* 


V  fnipi  m  dH.BBde  Hbm  baghi 

toiffi  •>  next  mim  :»  leaq 


dM  be^ 

tem(t2  :«  tempi; 

teiiq>l  :*  tonpl  ->  &ext_num; 

cad; 

Old; 


ftmction  GEr_EXT(  num_ext:  uint):  ExtJType; 

mr  di^:  uint; 
hi^hi 

digit  :s  num  ext/100; 

GETJEXWf  :*  digit  +  0x0030; 
nuffljrait :«  num_ext  -  (digit  *  100); 
digit  num  ext/lO; 

<3ET.EXT(lf  :*  digit  +  0x0030; 
num  ext :«  num  ext  -  (digit  *  10); 

GET  EXTpl  :«"num  ext  +  0x0030; 


procedure  1NCREMENT_MSG(  tcall;  Callsign^Type;  rar  next_sn:  uint; 

mjiead:  ^^Soufcejtoo^;  teter:  Letter_Amy;  ulong;  ext:  Ext_Type); 

far  teiiq>l,  tenia,  new_iiode:  ‘^Souice^Record; 
ind»:  uchar, 


index  :»  teall{0]  -  0x41; 
ten^l :» letterDiidex]; 

iihBe  tenqil  <  >  miff  and  templ->call  <  >  tcall  do  begin 
tenqp2 :»  tempi; 
tenqpl  :>■  teiiq»l*>aextjcall; 

end; 

if  tenqil  «>  miff  then  b^n 

new_node  :«  ALLOCATE(  1,  SlZE_OF(Souice_Record)); 
newjiode>>souice_num  :«  next_sn; 

GEi^NEXT_NUMf  m_head,  nex^sn); 
iiew_no(te’>call :«  tcall; 
new_node->aekcted.num_sd[ 0x0000; 
new_node->next_ext  :=  0x0002; 
iiew_iiode->num_act :«  0x01; 
new_node->nextjiium  :=  null: 
newjiode->next_call  ::>=  miff/ 
temp2''>next_call  new_node; 

mail  num  new  node->soiirce  num  *  0x00010000  +  0x0001; 
ext :»  "001"; 
tempi :»  m_head; 

if  tanpl->souice_num  >  new_node->souice_num  then  begin 
new_iiode->nextjium  :=  m_head; 
m_lwad  new_node; 
end; 

dse  begin 

whfle  tempi- >source_num  <  new^node- >  source_num  and 
tmnpl->nait_num  <  >  miff  do  begin 
temp2  tempi; 
tempi  :=  tempi- >next_num; 

Old; 

if  tmnpl->next_num  »  miff  ttien 
tmnpl->n«t_num  ;=  imw_node; 
dse  b^in 

new_node->next_num  tempi; 
temp2->next_num  :=  new_node; 
end; 
end; 
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lM|il->iiinijKt ieiiq»l'>iHiiii_act  +  1; 
imAjnun  leii9l->ioiifoe_miin  *  QxOOOlOOOO  +  tNiq>l->next_ext; 
ext  :*•  GET_EXT(  teii9l->n^jext); 
if  teiiq[»l->ni^jBxt  <  maxjaalkm 

teiiq>l*'>iiext_eKt  :*  te^l->nextjext  +1; 
dK  tei^l>>iiext_cxt  :*  QxOOOl; 

cad; 

pvooedHre  COMPACT_MAIL(  var  mlist:  ‘*^oufce_Anay;  llist:  Lettar_ArrBy); 
bcfbi  {  This  function  deletes  mail  fifes  wUdi  are 

{  exfMiation  dates. 

w 


thdr} 

} 


this_fife: 

IfemeJType; 

rfife: 

‘^Fife_Type; 

now: 

ukmg; 

ex]Mre: 

ulong; 

caU: 

Callsign_Type; 

now :»  GET_TIME( ); 

this^fite  :*  (^_FIRST_FILE(  date,  en^ttyjtring)', 
whOe  diis  file  <  >  em^  string  do  be|^ 
rfife  :»  OPEN  FILE(  &s  fUe); 

FILE.S£EK(  26,  ffile); 
exfMie  :*  READJPnJEC  1,  4,  rfile); 
if  exim  <»  now  then  bedn 
FILE  SEEK(  2,  rfife); 
call :»  BEAD  FILE(  1,  6,  rfUe); 

DELETE  FILE(  this  fUe); 
DECREIiffiNT_MSG(  caU,  mUst,  Uist) 
cod; 

cbe  CLOSE  FILE(  this  file); 

this_fife  :«  GET,NEXf_FILE(  date,  this_file); 

cod; 

end; 
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pwiwiwf  QErjNEXT_NUM(  mlist:  ‘^Souice.Reooid,  var  next.n); 

var  { Finds  die  next  umised  source  number.  } 

teniK  ^Source  Seooid: 
done:  boakmi; 


done  :• 

wC  done  do  bod^ 

If  acat.fli  <  OxFFFP  ttca 
nert^sn  :«■  next.sn  +  1; 


tad; 


*rv» » « 


temp  :*■  mHst; 


1; 


sHUk  temp  <  >  null  and  tenqh>  source jium  <  next_sn  do 
temp :» tenq>->next_num; 

If  temp->8ouree.nttm  <  >  next.sn  then 
done :« true; 


ftnctfon  MAKE_FILE_NAME(  source:  Callsign JType;  ext:  Ext_Type):  Name_Type; 

bcgfai 

MAKE  FILE  NAME(P..l] :«  *  *; 

MAXE^FItE  NAME12..7] :«  source; 

MAKE'fILE'NAME[8]  :- 
MAKE'fiLB  NAME(9..U]  :«  ext; 

•ad;  ”  " 
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NNAMi(  alii:  ^looieeltooid;  nami:  akMig):  NmeJType; 


i,e:  via; 

iMMift*  ^Sowo  RBOOid; 

at:  Bxtjiy^ 

K  CidisigiiJlVpe; 


s :«  GET_li^  nmum);  {  louice 

e :«  CHBTJLSI(  nmum);  {  exteasion 

at  :*»  e); 

■ode nl^; 

iridb  node  <  >  mitt  and  iiode->aouioe_niiin  <  >  s  do 
node :«  node->nat_niim; 

IT  node :«  md/thn 

GET.NAME  :>■  enqity^string', 


louxoe  :■*  node->caU; 

QETJNAME  MAKE_FILE_NAME(  source,  at); 


!  IN1TIALIZE_MAIL_FILE(  source:  CallsignJType;  mnum:  ulong); 

at:  ExtJI^;  iagth:  ulong); 

or  new^fik:  Itome.Type; 
f:  ~  ‘•‘Filejr^; 

new  file  :«  MAKE  FILE  NAME(  source,  at); 
f  (X>EN_FILE(  new_l^); 

WR1TE_FIL]E(  matt  Jlag^  2,  f); 

WRTTE.FILEC  mnum,  4,  f); 

WItnE~FILE(length,  4,  f); 

CLOSE_FILE(  ncw.file); 

{  Of  Procedure  lNniALlZE_MAlL_FILE. 


} 
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pmdwrt  REJNTTJILEC  fik.name:  NameJType;  mail_nuin:  ukxig); 

wv  tJSkK  ^PileJI^pe; 
fjeogfli:  uloog; 

Im||b 

r  file :«  OPEN  FILE(  file  name); 

RLE  SEEKi  fl,  t  file); 

fjttiik READ_F1LE(  1.  SIZE.OF(  ulong),  r_fite); 

DELEIB  F1LE(  file  name); 

INmAlJx.MAnjFILEC  fikLname(2..7],  mail.num,  file_iiaiiie(9..11],  f.kngth); 

cad; 

ftmcfion  CRC_CHECKS_Oin'(  filejiaine:  NameJType;  start:  uint;  stop:  ukmg; 

crc:  uint):  bookan; 

{  This  algoritfim  assumes  Ae  crc  is  a  simjde  diedc  } 
{  sum.  } 

var  num  bytes,  i:  ukmg; 

r^filc:  ^FikLType; 

sum:  uint; 

next_char:  uchar; 

bc^ 

if  crc  «  0x00  then  CRC.CHECKS.OUT  : »  true; 
dMbegfai 

sum :»  0x00; 

r  file  :«  OPEN  FILE(  fik  name); 
nLE.SEEK(  stit,  r_filc);  ” 
for  i :«  1  to  (stop  -  start)  do  b^ln 

next_char  :»  READ_FILE(  1,  1,  r_fUc); 
sum  :»  sum  +  next_char; 
radj 

CLOSE_FILE(  file.name); 

CRC_CHECKS_OIJT  :=  (  sum  =  crc); 

end; 

end; 

ftmetion  CHANGE_CASE(  str:  Byte_Anay;  len:  uchar):  Byte_Anay; 

▼ar  i:  uchar;  {  Changes  any  ASCII  upper  case  letters  found  within} 

begin  {  ’stt^’  to  lower  case.  Returns  the  modified  string.  } 

fnri  :s  Otolen-1  do 

if  str[i]  >  0x40  and  str[i]  <  0x5B  tiien  str[i] :»  stifi]  +  0x20; 
CHANGE_CASE:=  str, 
end; 
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'tiiirilwJHyyPMIt  CHBOGf  shik  Hum  IViik  omU  mou  idkiw: 

IBi^jpe;  nieJDii^Aiiqr;  oonptype:  Coofweision.Aniy  ):  baolw? 


far  food,  ok:  hoafcaa; 

rjflte:  "t>ilc_T!^; 

cTd:  udiar, 

i,  body.oltet:  umt; 
to:  tttoog; 

can:  CaUsi^.TVpe; 

ext*  Ext  Type; 

bcgli 

good  :■(  tone; 

r.llto :«  QPEN.FILEC  fite.iiaine); 


i :-  8EADjnLE(  1,  2,  rJOe);  {  Read  flag  } 

tf  i  <  >  ni^ Jhg  tiiea  good  :«  false; 

to  :»  READJFS£(  1,  4,  r_fito);  {  Read  mail^number  } 

if  to  <  >  11^  num  then  good  :»  fiOse; 

to  :«  READ.niE(  1,  4,  r.fUe);  {Read length  } 

if  to  <  >  LENGTH(  fito  name)  tfioi  good  :»  false; 
c  :-  READ.FIUEC  1,  1,  r_file)T  (  Read  file^typc  ) 

ck :»  false; 

fori :«  OtORuntfypes- 1  do  (  Check  file_type  against  all  valid  file^types  } 

if  c  «  filetypeH]  tten  dc true;  _ 

tf  not  (dc aua  good  :»  false;  {  HEADER_CH£CK,  continued.  } 

c  :*■  READ_FILE(  1,  1,  r_fi]e);  {  Read  compression^type  } 

<dc  :«*  fidse; 

for  i :»  0  to  numcomps  >  1  do  {  Check  comi»esuon_type  against  all  valid  ) 

tf  c  »  oomptypefi]  then  ok  :»  true;  {  compressiofi_types  } 

if  not  <dc  thoi  good  false; 

bodyjc^tet :»  READ_FIL£(  1,  2,  r_file);  {  Read  body_ofrset  } 

c  :«  READ_FILE(  1,  1,  r_nie);  (  Read  dovmload_count  ) 

caU  :»  READ  FILE(  1,  6,  r  ffle);  {  Read  source  } 

can  :«  CHANGE  CASE(  caU,  6); 
if  can  <  >  CHANGE_CASE(this_fUe[2..7],  6)  then 

good :» false;  { Qieck  stmrce  vs  file_name  } 

c  :»  READ  FILE(  1,  1,  r  file);  {  Read  priority.  >^iat  to  do  with  it  is  undefined.) 

to  : «  READ_FILE(  1,  4,  r.file);  {  Read  upload  time  > 

if  to  >  «  GCTjnME( )  tli«  g^  :»  false; 

to  READ_FILE(  1,  4,  r_file);  {  Read  esqaiaticm  time  } 

tf  to  <  GET_TIME(  )  tbna  good  :=  fkise; 

i :»  READ_Fn.E(  1,  2,  r_file);  {  Read  leading  qnces  in  file  name.  } 

tf  i  <  >  thTs^filefO..!]  thin  good  false; 

can  :»  REA]JfILE(  1,  6,  r.file);  {  Read  file  name  } 


if  CHANGE.CASE(  can,  6)  <  >  CHANGE_CASE(  this.file[2..7],  6)  ^ 
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food  :*  trise;  { Check  vs  known  file_naine  } 

cad  :*■  READ  FILE(  1,  3,  r  file);  {  Read  file  extension  } 

IT CHANGE.CASE(  ext.  6)  <  >  CHANGE.CASE(  file.naine[9..11],  6)  then 
good fidie{  { CSieck  vs  Imown  file  ext  } 

c  :*■  READ_nLE(  1,  1,  r_file);  {  Read  num_destin^  lions  } 

If  c  >  (M)9ttenfoc^  fake; 
if  food  ft**"  bofin 

If  c  >  QxOTttacac  0x07; 

fori:*  1  toe  do  { Read  pest  all  destinations  } 

call :«  READ.FILE(  1,  6.  r.file); 
body  ofket  :*•  boity  ofi^  >  min Jtle  lengtit  -  c*6; 

c  r-'READ.FILEC  1,  1.  r.file);  {  Read  dtle.length  } 

fori:«ltocdo  { Ri^  title  } 

d  READ_FILE(  1,  1,  r.file); 
body_ofket : »  body_offsrt  - 1  -  c; 

c  :*  READ_FILE(  1,  1,  r_file);  {  Read  keyword Jengdi  } 

for  i : «  1  to  c  do  { Read  keywords  } 

d  :«  READ_FILE(  1,  1,  r_file); 
body joffiset :  =  body_offset  - 1  -  c; 

body.offset  :=  body.offset  -  4;  {  Account  for  2  checksum  uints  } 

if  body^offset  <  >  0  then  good  : »  false; 
end; 

HEADER  CHECK  :»  good; 

end;  ~  { of  HEADER  CHECK()  } 


ftinctkm  MSGJTCX  file_name:  Namejiype;  call:  Callsign_Type):  boolean; 

var  f:  ‘^File_Type; 

numjdest,  i:  uchar; 
dest:  Callsign_Type; 

b^in 

MSG  TO:»  false; 
f  :*  OPEN  FILE(  file  name); 

FaE_SEEI^  «/,  f); 

num_dest  :=  READ_FILE(  1,  1,  f); 

If  numjdest  >  0  and  num jtot  <  0x08  then  do 
for  i 1  to  num  dest  do  b^in 

dest  :=  REAd3.FILE(  1,  SIZE_OF(CaUsign_Type),  f); 

If  dest :  s  call  then  MSGJTO  :  =  true; 
end; 

CL0SE_F1LE(  file.name); 
end; 
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L*  OyiiigBjiype;  ?ar  m.heid:  '^emotjtteotd; 
csjKny:  Letter.Arnqf;  iiext.n:  uint;  tad:  Nura.Mul); 


lUeiiHiie: 

ft 

Impl,  teiiip2: 
aewjwde: 
mimjlest,  i: 
dljpwt,  j: 
index: 


“T^Jiype; 

^Soum.Reoocd; 

^Soufoejteooid; 

udiar, 

udiar;  { download  count 
unit; 


nmn^foiind:  Num.Mail; 

s.liat:  Mail.Array; 

mjmm,  uljinie:  uksng;  {  mailjnumber,  \q>loadjime 

n - 

IN|III 

niim_found :  «>  0; 
index  :■*  0; 

fik.name  GET_FIRST_FILE(  date,  mpty_string)\ 
whfle  file  name  <  >  enywy  string  do  bc|^ 
f : «  OPEN_FILE(  fikLiume) 

FILE_SEEK(  mn,  f); 
m  num  :»  READ  FII£(  1,  4,  f): ' 

F^  SEEKidc-nd,  f); 
dl  count READ  FILE(  1,  1,  f); 

FdLe.SEEKC  itf  •  1C.  f); 

ul  time  :»  READ  FII^  1,  4,  f); 

f£e_SEEK(  nd  •  er,  f); 

num  dest  READ  FILE(  1,  1,  f); 

CLOSE.FILEC  lile_i^e); 

if  ul.time  >  0  then  {  Only  cmisider  completely  uploaded  files. 
If  numjdest  -  0x00  mr  numj^  >  0x07  then  be^  {  to  ’ALL’ 
num_found  num_found  +  1; 
s_li^index.  .index  +  3]  :=  m_num; 
intex  :=  index  +  4; 
end; 

dse  if  dl_count  <  numjlest  then 

if  M^JTO(  file_name,  call)  then  b^ln 
num_found  :=  num_fbund  +  1; 
s_li^index. .index  +  3] m_num; 
iiideK  index  +  4; 


end; 

file.name  :»  GET_NEXT_FILE(  dau,  file_name); 

ffad* 

j  :«  caU[0]  -  0x41; 
tmnpl  :*  cs_array[j]; 


) 

> 


) 

} 
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ulAi  leiqpl  <  >  mM  tad  templ->call  <>  call  do  begin 
leflqi2 :« teflq>l: 
len^l :» teiig>l*>next_call; 
end{ 

If  tenq^l  »  jim0  tihea  bcgla 

new_node  :«  ALLOCATE(  1,  SIZE_OF(Souite_Recofd)); 
aew  node  :■>  fouroe  num  :«  vtaA  n; 

GETNEXT.NUMC  m.head,  next  In); 
new_node->call :«  caU; 
ncwjD0d0‘>adecl6d.niiin_ael :»  num_foiind; 
fiew_node->aelected.idi :«  s.list; 
new_node->next_inail :»  QxOOOO; 
new_iiode->nextjlir :»  0x0000; 
newjiode->next_ext :«  0x0001; 
newjiode->num_act 0x00; 
new_node->nextjium :«  nu//; 
newjiode->next_call null; 
tempi  :»  m_head; 

if  tempi- >aouiGe_num  >  fiew_node->souice_num  thm  begin 
newjiode->nat_num :«  m_head; 
m_h^  :»  new_node; 
end; 

dee  begin 

abile  tempi- >source_num  <  new_iiode->source_num  and 
tempi- >next_num  <  >  nulldoheg^ 
temp2  tnnpl; 
tempi :« tmnpl->  next_num; 

end; 

if  tempi  ->  nmitjium  «  null  then 
tempi- >next_num  :«=  iwwjiode; 
dse  begin 

new_node->next_num  :=  tempi; 
temp2->next_num  :=  newjiode; 

Old; 

end; 

Old; 

dse  begin 

tempi- >sdected.num_sel  num_found; 
tempi- >sdected.sd s_list; 
tempi- >next_mail 0x0000; 
tmnpl->next_<lir  :=  0x0000; 
end; 

nael :«  num_found; 
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plilliM  BA16AX.SEtiCT10N(  t.tttuet:  Pdait;  call:  CaUi^.Type; 
mt  njtaad:  ^ItoweeJRaeoRl;  cs.anay:  Letter.Anay;  next.n:  uint;  nad:  ^him^Mail; 
flirar:  vctai); 


ffie  name: 

Name^Type; 

ft  " 

^Pile^yp®! 

sjist: 

Sekc^Ust; 

1^1,  Ienqi2: 

""SoufM.Reoofd; 

new.node: 

‘^Soruoe^Reoofd; 

dest  can.* 

Callstgn.Type; 

BatJ: 

uint; 

m_nom: 

ulong; 

ab^  ok: 

boolean; 

num_s,  i: 

udutf; 

stnidj: 

uint; 

headerjtem: 

uchar; 

first,  second: 

bodeui; 

reiop,  logop,  j: 

uchar; 

itetn.len,  hjen: 

uchar, 

s_int,  hs_int: 

uchar; 

mjnt,  hm_int: 

uint; 

ijiit,  hljnt: 

ukmg; 

oompaiejtem: 

Byte^Array; 

h^string: 

Byte_Array; 

numjdest,  t^len: 

uchar; 

ul_time: 

ulong; 

bcgba 

almt :«  Cube; 
nuin_s :»  s_struct[l]; 
s_listnuin_sd  :=  0; 
listj :«  0; 

file_iiaine  :*  GET_FIRST_FILE(  date,  eng}ty_string); 
wbte  file  name  <  >  en^My  string  and  sol  abort  do  begin 
f :»  OPEN  FILE(  file  name); 

FILE_SEEK(  mn,  f); 

mjium  READ  FILE(  1,  4,  0; 

FILE_SEEK( 

ul_time  :=  READ_FIL£(  1,  4,  f); 
if  uljime  >  0  ttoi  b^|in 
false; 

FILE  SEEK(i»/-ef,  f); 

numjdest :«  READ_FILE(  1,  1,  f); 

if  num  dest  »  0x00  or  num  dest  >  0x07  then  ok  :  =  true; 

«be  “ 


fur  j  :  s  1  to  numjdest  do  bqdn 


dest  call READ  FILE(  1,  6,  f); 

if  d^GE.CAS)^  dest_caU,  6)  =  CHANGE_CASE(  call,  6)  then 
ok :« tiiie; 

end; 

if  (dc  thra  begin 
structj 2; 
first :« true; 
second :»  false; 
i  :=  0 

while  i  <  nuin_s  >  1  and  not  abort  do  begin 
idop s_struct(stnjctji]; 
structj  :=  stnictji  +  1; 
h_itcm  :=  s_stnicUstruct_i]; 
s»ruct_i  :=*  structj  +  1; 
itemjm  :=  s_structCstruct_i]; 
structj  :=  structj  +  1; 

if  relop  =  equal_str  or  relop  =  not_equ_str  then  begin 

compare Jtem  :=  s_struct[structj.. (structj  +  itemjwi  -  1)]; 
comparejtem  :=  CHANGE_CASE(  compare  Jtem,  item  Jen); 
structj  :  =  structj  -t-  item J«i; 
if  h  item  <  ds  then  begin 
FILE_SEEK_SET(  hjtcm,  f); 
h_string  :=  READ_^E(  item  Jen,  1,  f); 
h_string  :=  CHANGE_CASE(  h^string,  item  Jen); 
seccmd  :  =  STRING_  COMPARE(  h_stiing,  comparejtem); 
if  telop  not^equ_str  then  second  :  =  not  second; 
end; 

else  b^in 

FILE_SEEK_SET(  nd,  f); 
num_dest  :=  READ_FILE(  1,  1,  f); 
if  h  Jtem  =  ds  then  begin 

Hr  numjdest  >  0  and  num_dest  <  0x08  then 
if  item  Jen  =  6  then  begin 

for  j  :  =  1  to  num_dest  do  begin 
h_string  :=  READ_^FILE(  1,  6,  f); 
h_string  :  =  CHANGE_CASE(  h_string,  6); 
if  not  second  then 

second  :  =  STRING  COMPARE(  h_string, 
comparejtem); 

end; 

end; 

else  second  false; 
else  if  num_dest  >  0x07  then  begin 
h_string  :=  READ_HLE(  42,  1,  f); 
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h.itriag  :*  C3IANQE_CASE(  h_ttfiQg,  42); 

Moond  :»  STRING^ni^  o(Hiq»re_item,  h_stiing); 

co^ 

dM  second :»  fdae; 

if  rdop  «>  notjuptjtr  then  second  not  second; 
end; 
dse 

if  h_item  >  ti  tbos  begin 

FILE  SEEK(  ds  +  num  dest*6,  f); 
t  IcnT-  READ  FILE(  I,  1,  f); 
h_slring  :=  R£^_FILE(  tjcn,  1,  f); 
hustling  :=  CHAITOE^CA^  h_string, 
second  : »  STRING_FDn>(  compaiejtem,  h_string); 
if  relq>  «  not_equjitr  then  second  : «  not  second; 
end; 
else 

if  h_item  =  kw  then  be^ 

FILE_SEEK(  ds  +  num_dest*6,  f); 
t  len  :=  READ  FILE(  1,  1,  f); 
nLE_SEEK(  t  icn,  1,  f); 
tjen  :=  FILE_READ(  1,  1,  f); 
h_string  :=  READ_FILE(  t_len,  1,  f); 
h_string  :  =  CHANGE__CASE(  h_string,  t_len); 
second  :  =  STRING_roTO(  comparejtcm,  h_string); 
if  relop  notjtqu_str  then  second  : »  not  second; 
end; 

else  abort :  =  true; 

end; 

end; 

else 

ifh  item  <  nathenb^n 
FILE_SEEK_SET(  hjtem,  f); 
if  itemjen  =  1  then  begin 
s_int :  =  s_struct[struct_i]; 
struct  i  :=  struct  i  +  1; 
hsjnr:=  READJFILE(  1,  1,  f); 
hl_int  :=  0x00000000  +  hs_int; 
l_int ;  =  0x00000000  +  s_int; 
end; 

else  if  itemjen  =  2  then  begin 

m__int  :=  s_struct[struct_i..struct_i  +  1]; 
struct  i  :=  struct  i  +  2; 
hmjnt  :=  REAl5^FILE(  1,  2,  f); 
hl_int :  =  0x00000000  +  hm__int; 
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TTTLUrOXLl 


end; 

dM  if  item_lea  «  4  then  begin 

IJnt  :*  t_8tnict[stnict_i..8tnictj  +  3]; 
lituct  i :«  itruct  i  -f  4; 
hl.inf:*  REAdJfILE(  1,  4,  f); 
end; 

dee  abort :« tnie; 
if  not  abmt  then 

if  idop  OB  equal Jm  then 
second  :*»  (  M_mt  = 
dee  if  relop  »  great  Jm  then 
second  : »  (  hl_mt  >  l_int); 
else  if  rd<v  «  lessjm  then 
second  :  “  (  hl_int  <  IJnt); 
ebe  if  tdt^  s:  not_equJm  dien 
second  :=  (  hl__int  <  >  I_int); 
else  If  reiop  =  gr_fqujm  then 
second  :  =  (  hl_int  >  =  l_int); 
dse  if  rdop  =  le_equjm  then 
second  :  =  (  WJnt  <  =  l_int); 
dse  abort :»  true; 

end; 

else  ab(»t :  =  true; 
if  not  abort  dmi  begin 

i  :*=  i  +  1; 

logop  :=  s^structCstructJ]; 
if  logop  -  Ijond  then  be^ 
stnictj  :=  structj  +  1; 
first :  =  (first  and  second); 
end; 

dse  if  logop  =  l_or  then  begin 
structj  :=  structj  +  1; 
first  :=  (first  or  secemd); 
end; 

else  first  (first  and  second); 

Old; 

end; 

if  fimthen  begin 

sjist.num_sel  :=  sjist.num_sel  +  1; 
s_list.sel[l5tj..listj  +  3]  :=  m_num; 
listj  :»  listj  +  4; 

Old; 

Old; 
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mejitine :«  GBr~NEXT_FlLE(  dm,  file_naiiie); 

cad; 

If  abort  then 

error  :*  er joortyJbmedjel; 

dbe  bcgfai 


error no  error, 
j  call(0)”  0x41; 
tempi :«  csjnayQ]; 

while  ten^l  <  >  nidi  and  templ->call  <>  call  do  begin 
temp2 :« tempi; 
trnnpl  :«  tempi- >next_call; 
end; 

If  tmnpl  »  null  then  begin 

iicw_nodc  :=  ALLOCATE(  1,  SIZE_OF(Source_Rccord)); 
new_iiode  :=  soiiicc_num  :=  ncxt_sn; 

GEf.NEXT_NUM(  m^head,  next^sn); 
new_node->call  :*  adl; 
newjaode->selected.num_sd  :=  s_list.num_sd; 
new_iiode->selected.sd s_list.sel; 
ncwjtiodc->ncxt_mail  :=  0x0000; 
iiewjnode->iiextjdir  :=  0x0000; 
iiew_iiodc->iicxt_ext  ;*=  0x0001; 
iicw_node->numjact  :*  0x00; 
fiew_iiode->iiext_num  :*  null; 
ncw~node->iiext_call  :=  null; 
tmnpl m_head; 

if  tenpl->souicc_num  >  iicw_node->sourcc_num  then  b^in 
iiew_node->next_num  :=  m^head; 
m_l^  :=  iicw_nodc; 
end; 

dseb^in 

while  tempi- >  source_num  <  ncw__node->sourcc_num  and 
tempi- >next_num  <  >  null  do  be^ 
tmnp2  :=  tempi; 
tempi  :=  tempi- >  next^num; 

Old; 

if  tempi  ->  iiext_num  =  null  then 
tempi- >next_num  :=  new_node; 
rise  begin 

ncw_node->next_num  :=  tempi; 
temp2->nm(t_num  :=  new_nodc; 
end; 
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end; 


leiiq>l'>sdected.nuin_sel  :«■  sjistnuin_sd; 
tefi9l->flelec(ed.ad  :*■ 
teiiq>l->iiext_iiiail 0x0000; 
teiiipl->iie9itjdir 0x0000; 


fuel  :*  sjist.num_ad; 


procedure  CX)PY_HEADER(  fUejuune:  Name.Type;  rar  buffer:  Byte_Anay; 

tS  index:  ulong); 

mr  r_file:  ""File^Type; 

b^yj>ffaet:  uint; 

begin 

r  file  OPEN  FILE(  file  name); 

HLE  SEEK(  bo,  r  fUe); 

body'ofGKt :»  READ  FILE(  1,  2,  r  file); 

FILE“sEEK_SET(  0,  r file); 

buffe^index.. index  +  bodyj)ffset  - 1)  :=  READ_FILE(  body_offset,  1,  r_file); 
C1jOSE_FILE(  file.name); 
index  :=  index  +  body_offset; 

Old; 
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to  WATT 

« - 

OCBH 

filetypeCfQ :«  QxOO; 
fiktype(l] :«  QxOl; 
file^wp]  :«  0x02; 

:«  0x03; 
fiktype[4] :«  0x04; 
filetype[S] :«  OxOS; 
fi]etype[6] :»  0x06; 

filetypefT] :  *  0*07; 

fiktypeCS] :«  0x08; 
fi]etype(9]  :-0x09; 
fiktypeClO] :«  OxOA; 


fitetype[ll]  :=  OxAO; 
filetype(12]  :=  OxAl; 
filctype[13]  :=  0xA2; 
filaype(14]  :=  OxFE; 


(  PACSAT  File  Types  fnrni  H.  Price  } 

{ ascii  } 

(  RU/MBL  message  body.  Single  message.  } 

{  RU/MBL  import/export  file.  Multiple  message.  } 
{  UoSAT  Whole  Oibit  Data.  } 

{  Microsat  Whole  Orbit  Data.  } 

{  UoSAT  CPE  Data.  } 

{  MS/PC>DOS  .exe  fUe.  } 

{  MS/PC-DOS  .com  file.  } 

{  Kcfderian  dements  NASA  2'line  format.  } 

{  Kq>lerian  dements  *AMSAT”  format.  } 

{  Simple  ASCn  text  file,  but  compressed.  } 

{  PANSAT  File  Types.  } 

{  PANSAT  short  tdemetry  file.  } 

{  PANSAT  liMig  tdemetry  file.  } 

{  PANSAT  bax  tdemetry  file.  } 

{  User  defined  type.  User  must  know.  OxFF  } 

{  ’ESCAPE  ’  not  implemented  in  PANSAT  file  } 
{  headers.  } 


for  i :  =  IS  to  numtypes  •  1  do 

filetype[i] :  =  0x00;  {  Extra  space  for  types  defined  later.  } 

{  PACSAT  file  cmnpresdon  types  -  H.  Price.  } 
comptypefO] :  =  0x00;  { No  compression  } 

comptype[l]  :=  0x01;  { Body  compressed  using  PKARC.  } 

comptype(2] :  *  0x02;  { Body  compressed  using  PKZIP.  } 

comp^[3]  :=  OxFE;  {  Other,  user-known  compression  type.  } 

for  i  4  to  numcomps  - 1  do 


compQ^fi]  ;  =  0x00;  {  Extra  space  for  compression  types  defined  later.  } 

next_sourcc_num  :=  0x0001; 
for  1  :=  0  to  25  do 

first 

mail_h^  :=  mdl. 


mid; 
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tlWM 

fifwiWAnrtottiiie 

lAm  meniidc].iiiail_nuin_,req 

Im^ 

If  mail  mintofluik]  •  QxOOOOOOOO  tbtn  begin 
irki«tliaiiik]  >  MEM  SPACE()tben 
GOMPACT  MAIL(  maU  bead,  fint  kt); 

VkoglbDink]  < «  MEM_SPACE(  ) bc^ 

INCREMENT_MSG(  dientjcalipink],  iiext_souioe_num,  inail_head,  first_let, 
mail_niiffi,  ext); 

INlTiAIJZEJMAIL_FILE(  ctientjcall,  mail^num,  ext,  lengthpink]); 
ontpiit  inc[UAk].fnail_nimi_fe^  mail.num,  0x00000000,  nojtrror); 

end; 

dae  begin 

output  inc[link].iiiail_num_re^  0x00000000,  0x00000000,  er_no_room); 
time  :*  GET  TIME(  ); 

report  :=  FORMAT.EVENT„REPORT(  mailbox Jull,  time); 
output  el>event_rqK^  tqxnt); 
output  oc.full_mailbox; 
end; 
end; 

dse  begin 

ffle^name  :»  GET_NAME(  mailjiead,  mail^numbofluik]); 
if  fUe^name  «  ar^jttrmg  then 

output  incpink].ii^_numjre^  inail_numb«rilmk],  0x00000000, 
trjtojsuch Jlkjmmber)\ 

dsebqdn 

rfile  : «  OPEN  FILE(  file  name); 

FILE  SEEK(  67  read  1116)7 

file^taigth  :«  REAd7.FILE(  1,  SIZEOF(ulong),  rfile); 

if  lengthpink]  <  >  filejength  then 

output  mcpink].mail_num_resp(  mail^number,  0x00000000, 
er_badyomimie); 
else  b^^ 

file.oft  ec  =  GET_LENGTH(  filc^name)  +  1; 
if  filejoffset  >  =  lengthpink]  then 

output  mcpink].inail_num_re^  mail_numberPink],  0x00000000, 
er Jilejampleu); 

dsebqdn 

if  filej>£fset  <  42  then  filejoffset :  -  0; 
output  mcpink].mailjnum_Te^  mailjnumberpink],  file_offset, 
no_envt); 
end; 
mid; 
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taiWAirtonne 

uta  mcniiik].iiiail_doie_req 

fiknemr  ;*  nojnror, 
haHujac  :*  QxOOOO; 

fik.iiaine  :»  ^r_HAME(  mail.head,  mail.nuntefliiik]); 
if  ^.nuiie  *■  en^.striiig  thai  fUejenor : »  erjiojvom; 

dw  bcski 

OPEN  FILE(  file  nam^;  ^ 

F1LE_SEEK(  mil,  ifUe); 
mail  num  READ  FILE(  1,  4,  rfile); 
file.tength  REAiTfiLEC  1,  4.  rfile); 
if  GET_LENGTH(  file_name)  >  -  file Jength  tiien  begin 
tf  11^  num  «  QxdoOOOOOO  then  b^ln 
FnXSEEK_SET(  mn,  rfile); 

WRITE_FIlj^  mail_numbCTPuik],  4,  rfile); 
fmri  :s  Oto  3  do 

header_crc  :  =  header_crc  +  mail_number(link][i]; 

end; 

time :»  GET  TIME(  ); 

FILE_SEEKJeT(  ut,  rfile); 

WR1TE_FIL£(  time,  4,  rfile);  {  Write  uplood^time.  } 

fori:s0to3do 

header j:rc  :<=  lieader_crc  +  time[i]; 
time  time  +  dtfaubjtay_time\ 

WRITE_FILE(  time,  4,  rfile);  {  Write  expirc_time.  } 

for  i :«  0  to  3  do 

header  crc  header  crc  +  time[i]; 

WRITE_ra^  file^namefO..?],  8,  rfile); 
for  i :  s  0  to  7  do 

header  crc  : »  header_crc  -t-  file_name[i]; 

WRITE_Fn^  filc_iiame[9..11),  3,  rfile); 
for  i 9  to  11  do 

headCT_crc  :=  headcr_crc  +  file_name[i]; 
num_dest READ^FIl^  1,  1,  rfUe); 
if  num  dest  >  0  and  num  iest  <  8  then 
FnX.SEEK(  num_dest*6,  rfile); 
dK  if  num  dest  >  7  then 
FILE  SEEK(  42.  rfile); 

j  :»  READ_FILE(  1,  1,  rfile);  {  Read  tiUeJength.  } 
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} 

} 


F1LE.SEEK(  ifUe); 

j  :»  READ  FiLE(  1,  1,  rfik);  {  Read  k^woed  leqght. 

FILE.SEEK(j,  rfile); 

i :»  READ_FnJB(  1,  2,  rfile);  {  Read  header  check  fum 
If  i  >  Othttbciki 

header  cic  :«  header  cic  +  i; 

RLE  SEEK(  -2,  ifile); 

WRniE.FlLE(  headerjoc*  2.  ifile); 
eod; 
cad; 

CLOSEJPILE(  file.name); 

If  req_i^)(link]  ttm  bc]^ 

if  not  HEADER_CHECK(  file^naine,  inail_number(link],  filetype,  comptype) 
fhea  file.enor :»  erjfadjt^der, 
fiff  begiii 

Ifile  OPEN  F1L£(  file  name); 

FILE  SEEK(  bo,  rfUe); 

body'ofSwt :»  READ  F1UE(  1,  2.  rfUe); 

FILElSEEK_SEr(  bo^_offsct  -  4.  rfile); 
headff  cic  READ  I^JE(  1,  2,  rfile); 
body  ^  READ_HLE(  1.  2,  rfile); 

CLC»E_FILE(  fUe.name); 

If  not  (5iC_CHECKS_OUT(  file^name,  0,  body_offset,  header__crc)  then 
fik.enor erjiieaderj^<^' 

dse  ir^  CRC_ciflECKSjbUT(  file.name,  body_offset,  filejength, 
bodyjac) 

thenlilejaTor :  =  erJ)ody_dteck\ 

end; 

output  mc[link].inail_close_resp(  file_error); 
tf  file_enror  <  >  no_errortlMm 

RE_INIT__FILE(  fiie_naine,  mail_number[link]); 

end; 

Old; 


AmWAITtoMM 

«eiBri^.aMitjraev 


Old; 


fDe  BUM  :»  GET  NAME(  maU  he^l.  mail  number(Uiik]); 
ifkagllilliiik]  >  1^  SPACE( )  then 
COMPACT.MAIU  maUJiead.  fintjet); 

If  kofttipiiikl  <  »  SP  ACE(  )  and  fUe  name  <  >  emptf  string  tiMn  bcflD 

ffile FILeT file  name); 

FEJB  SEEK(  offiKtpink],  ^); 

WRlis  F1LE(  mailllink].  kiistfaOink].  rfik); 

CLOSE.Fn^  fye.name); 

output  mcnmk].mail_iecv_feip(  nojerror); 

Old; 


if  file^name  »  en^jttring  then 

oidput  mcnink].mail_iecvjresp(  er_bad_continuey, 

dsebci^ 

output  mcDink].mailj!ecv_ie9(  erjiojwm); 
time  :«  GET  TIME( ); 

report :»  FORMAT_EVENT_REPORT(  mailbax Jull,  time); 
output  d.event_rqx^  npcnty; 
output  oc.fuU^mailbox; 
end; 


firam  WATT  to  same 
idien  rocpink].msdect_ieq 
be^ 

fUe^errar  :*  nojerror; 
tf  3dtoct_struct[link](0]  »  panjel  tbmi 

PANSAT_SELECnON(  select_struct[link],  client_call[link],  inail_head,  firstjet, 
next_aouioe_num,  nael,  fUe^mor); 

dse  D^AULT_SEL£CT(  client_call(link],  niail_head,  firstjet,  next_source_num, 
nsd); 

output  mc[link].msdect_resp(  nsel,  fUejerror); 
end; 
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IklMWAiTtOSHM 
nkm  iiicClink].inailjdd_req 

iMgbi 

fiksjenw :«  er jpemUsskm^datied; 

fik.name  *  GHTJNAMEC  inail.h^,  inail_nuiiiber(liiik]); 

if  i^_iuune  ■>  a^ptyjtrbtg  tb» 

filejenor  erjtojudt  JUejmmber; 

dM  if  dknt jcallOink]  «  npsjx^  thoi 
filejerrcNr :»  nojsrmr; 
dMbc^ 

if  fi]ejiainet2..7]  <  >  dientjcalinink]  tfaoi  b^ln  {  A  client  may  only  delete 
ifUe  : «  OPEN  FILE(  file  name);  {  file  whidi  he  has  u{doaded  or  which  is} 
FItE.SEEK(  lid,  rfile);  f  addressed  to  him.  } 

numjle^  :»  R£AD_FIL^  1,  1,  rfile); 
if  num  dest  »  QxOl  then  be^ 

cs  r=  READ_FILE(  1,  SIZEJ)F(CaUsign_Type),  rfile); 
if  cs  »  client_call[link]  then  file_mor  :  =  nojerror; 
tad; 

CLOSE_FILE(  file_name); 

end; 

else  file^error  :■=  nojirror; 
if  file  enw  =»  no  error  then  bedn 
DiLETE_Fttl(  this.file); 

DECR£KflENT_MSG(  file_name[2..7),  mail_head,  first  Jet); 

end; 

oiiti^  mc[link].mail_del_resp(  file^aror); 
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vfA 


V.'  ' 


UMiWAirtoMM 
nhM  aM|BaK|.dbjwq 


If  nudljBiiiiibefOink]  <  >  (hDOOOOOOOO  Ubem  begbi 

fikjBttne  :«  QETJNAME(  miljbead,  ittail_nuiiri)ertlink]); 
if  fiiejDaine  »  en^jtrir^  Oca 

wrtput  iiic(Uiik].dinxtocy(  0,  erjiojitch JUejmuber,  Cdse); 
diebc^ 

body.offset :»  0; 

CQPY_HEADER(  fUe^nanie,  dirjiat,  bodyj>ffset); 
oi^Krt  iiic(Uiik].diiecli^(  b^yjoffM,  dirj^,  fake); 


die 

j  :»  cUent_calli1ink][0]  >  0x41; 
tempi :»  fintJetQ]; 

irtiile  tempi  <  >  nuU  and  temp->call  <  >  client_call[link]  do  begin 
temp2  :»  tempi;  tempi :«  tempi- >next_call; 
end; 

if  tempi : »  nuU  or  tempi-  >  selectBd.num_sd  =  0x0000  then 
output  mcnink].diie^ry(  0,  erjxUctionjsmpty,  true); 

dse  begin 

j  :=  0;  file_length  :**  0; 

while  tempi- >iiext_dir  <  =  tt»npl->sdected.num_sel  and  j  <  10  do  begin 
mailjium  :=  tempi- >sdected.sd[templ'>iiexr,dir]; 
file_name  :*  GEr_NAME(  mail^head,  mail_num); 
if  file_name  <  >  empty _string  thmi  b^in 

COPY_HEADER(  file_naine,  dir_dat,  filcjaigth); 
j:*j  +  l; 

Old; 

tempi ->iiext_dir  :=  tempi- >next_dir  +  1; 

Old; 

if  tempi- >iiext_dir  >  tempi- >select6d.num_sd  then  be^ 
done : »  true; 

if  temp->next_mail  >  templ->selected.num_sel  then 
tempi- >seTected.num_sel  :=  0x0000; 

Old; 

dse  (kxie  fake; 
if  illejength  »  0  then 

output  mc(link].diiectory(  0,  er_5ekctionjanpty^  true); 
dse  output  mc[link].directory(  fflejength,  dirjdat,  deme); 
end; 
end; 
end; 
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Aram  WAIT  to  same 
iriMB  iiicpink].inail_req 
begia 

if  inailjiumber[liiik]  <  >  0x00000000  then  begia  {  Particular  Ole  requested. 
fi]e_nanie  GCT_NAME(  mail^head,  iiiail_nuinber[link]); 
if  ^_iiaiiie  »  en^jttring  thoi 

oirtput  inc[link].i^  lesiK  er  no_such JUejnmber,  mail  number[liiik],  0, 
fiJse); 

Old; 

dse  bq^  {  "Nmct”  file  in  selection  list  requested, 

j  dient_call[link][0]  -  0x41; 
tempi  :«  Orst_let[j]; 

while  tempi  <  >  null  and  temp- >  call  <  >  client_call[link]  do 
tempi  tempi- >next_call; 

if  ( tempi  s  null  or  tempi- >selected.num_sel  -  0x0000  or 
tempi- >next_mail  >  tempi- >sdected.num_sel)  then  begin 
if  tempi  =  null  or  tempi- >selected.num_sel  =  0x00  then 
done : » true; 
dse  done  : »  false; 

output  mc[link].mail_re^  er_selection_empty,  0,  0,  done); 
end; 

else  b^in  {  Active  selection  list  found 

mail_num  :=  tempi- >selected.sel[templ->next_mail] 
filejname  :  ®  GET_NAME(  mail^head,  mail_num); 
if  iUe_name  : »  anpty_string  then  be^ 

tempi- >next_iiiail  ;=  tempi- >next_mail  +  1; 
if  tempi- >next_mail  >  tempi- >  selected.num_sel  then 

if  tempi- >next_dir  >  tempi- >selected.num_sel  then  begin 
tempi- >selected.num_sel  :=  0x0000; 
output  mc[link].mail_resp(  er_5election_empty,  0,  0,  true); 
end; 

else  output  mc[link].mail_resp(  erjelectionjtmpty,  0,  0,  false); 
else 

output  mcpink].mail_resp(  er_no_such JHejvumber,  mail_num,  0, 

false); 

end; 

else  begin  {  Good  file  number  found  in  select  list, 

rfile  :  =  OPEN  FILE(  file_name); 

FILE  SEEK(  ml,  rfile); 

filejciigth  :=  READ_FILE(  1,  4,  rfile); 

if  fiie_length  <  «  offset[link]  ^en  begin 

output  mc[link].mail_resp(  0,  mail_num,  0,  false); 

CLOSE_FILE(  file_name); 
end; 


•liy  bc^hi 

Fn£_SEEK_SET(  ofraet(Uiik],  rfUe); 
if  file_kiigth  -  offsetHink]  >  max  jdat  tboi  bc^ 

di^dat[0..ifiax _p(ka  - 1]  :*  READ_FILE(  max jfdat,  1,  rfik); 
output  inc[lifik].inail_re^  dir_dat,  mail.num,  max jfdat,  fate); 

Old; 

doe  begin 

iile_offset iile_tength  -  offsetflink]; 
dir_dat(0..  file^offset  -  1]  :=  READ_FILE(  file_o£rsd,  1,  rfUe); 
output  mc[link].mail_resp(  dirjiat,  inail^num,  fUe_offset,  fate); 
end; 

CLOSE_FILE(  filc.name); 

Old; 

end; 

end; 

end; 

end; 
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from  WATT  to  same 
wlieB  iiicnink].dl_ack 

be^ 

j  client_caU|1ink][0]  -  Qx41; 
teiiq>l  :»  first_let(j]; 

sHiile  tempi  <  >  nuU  and  temp->call  <  >  client_call[lifik]  do 
tmnpl  tmnpl->next_call; 

if  ( tanpl  <  >  nuU  and  tempi- >sdected.num_sel  <  >  0x0000  and 
tempi- >next_mail  <  -  tmnpl->selected.niun_sd)  then 

if  tempi- >selected.sel[templ->next_mail]  =  mail_number[link]  thra  begin 
tempi- >nmct_mail tempi- >next_mail  +  1; 
if  tempi- >next_mail  >  tempi- >seiected.num_sel  then 
if  tempi- >next_dir  >  tempi- >sdected.num_sel  then 
tempi- >selected.num_sd  0x0000; 

end; 

file_fiame  :  =  GET_NAME(  mail_head,  mail_number[link]); 
if  file  name  <  >  enq)ty  string  then  begin 
rfUc  ;=  OPEN  FIL^  file  name); 

FILE_SEEK_SET(  dc,  rfile); 
k  :=  READ_FILE(  1,  1,  rfile); 
done :  =  false: 

FILE_SEEK_^SEr(  nd,  rfile); 

num  dest  :=  READ  FILE(  1,  1,  rfile); 

CLdSE_FILE(  mtjame); 

if  num^dest  =  0x00  or  num_dest  >  0x07  then  done  :  *  true; 
else  if  MSG_TO<  file_name,  cUent^callpink])  then  done  ;  =  true; 
if  done  and  k  <  2SS  then  begin 
rfile  :  =  OPEN_FILE(  filejname); 
k  :=  k  +  1; 

Fn£  SEEK(  dc,  rfile); 

WRriE_FILE(  k,  1,  rfile); 

FILE_SEEK(  ds  -  sc,  rfile); 

if  num_dest  <  0x08  then  FILE  SEEK(  num  dest*6,  rfile); 
else  FILE_SEEK(  42,  rfile); 
j  :=  READ  FIL^  1,  1,  rfile);  {  Read  title  loigth. 

FILE_SEEK(j,  rfile); 

j  :=  READ  FILE(  1  1,  rfile);  {  Read  keyword  length. 

FILE_SEEI^  j,  rfik 

beader_crc  :=  READ_FILE(  1,  2.  rfile);  {  Read  header  check  sum. 
if  hea^r_cic  >  0  then  b^in 

header  crc  :=  header_cic  +  0x0001; 

FILE_SEEK(  -2,  rfile); 

WRrfE_FILE(  header_crc,  2,  rfile); 
end; 
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CL0SE_F1LE(  ffle.nune); 

end} 

end; 

end; 


frou  WATT  to  same 
wta  oc.list  mail 
bcgiii 

num.files :»  0; 

tf  bulletins  tbm  begin  { list  all  bulletins  } 

file.name  :«  GET_FIRST_FILE(  name,  -BULLETIN"); 
while  file.name  <  >  en^jttring  do  begin 
maii[num.files]  fiie_name; 
num.files  :»  num.files  +  1; 
filejaame  :*  GEr_NEXT.FILE(  name,  file.name); 
end; 

Old; 

if  messages  tbmi 

tf  to  then  b^in  {  List  all  messages  *to*  a  certain  callsign.  } 

file.name  :=  GEr.FIRST.FILE(  date,  empty  jtring); 
fdite  file.name  <  >  empty _stnng  do  b^in 
if  MSG.TO(  callsign)  then  begin 
mailTnum.files]  :=  file.name; 
num.files  :=  num.files  +  1; 

Old; 

file.name  :*=  GBr_NEXT.FILE(  dau,  file.name); 

end; 

end; 

else  if  from  tbmi  begin  {  List  all  messages  ’firom*  a  certain  callsign.  } 

sname[0..1]  "  ";  sname[2..7]  :=  callsign; 

file.name  :=  GEr.FIRST.FIIJE(  name,  sname); 
idiUe  file.name  <  >  empty  jtring  do  begin 
mail[num_files] file.name; 
num.files  :*  num.files  +  1; 
file.name  :*  GET_NEXT_FILE(  name,  file.name); 
end; 
end; 

else  be^  ( List  all  messages  } 

file.name  :  *  GEr.FIRST.FILE(  date,  emptyjstring  ); 
while  file  name  <  >  emptry  string  do  b^in 

if  filejiame[0..7]  <  >  -BULLETIN- then  begin 
nudl[num.files] file.name; 
num.files  :*  num.files  +  1; 
end; 

file.name  :«  GEr.NEXT.FILE(  date,  file.name); 
end; 
end; 

output  cc.mail.list(num.files  -  1,  mail); 

Old; 
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ftm  WAIT  to  MBW 
wbm  oc.post_biilletiii 
bcfhi 

INCREMENT_MSG(  "BULLEnN”,  next_souice_num,  mail_liead,  first  Jet, 
oiail.nuiii,  ext); 

rfile  :»  OPEN_FILE(  bulletin);  {  File  has  already  been  created  and  written  by  the} 

FILE_SEEK(  iiin,  ifile);  {  command  module.  Ifere,  we  just  keep  track  } 

WRITE_,FILE(  niail_num,  4,  rfile);  {  of  how  many  bulletins  are  active,  and  } 

FILEJSEEK(  nd-nd^  rfile);  {  write  appropriate  mail_number  into  the  file  } 
numjdest :«  READ_FILE(  1,  1,  rfile);  {  header.  In  this  case,  the  mail_number  } 
if  numjdest  >  0x07  then  {  will  not  accurately  reflect  the  metension  of  the} 

FILE_SEEK(  42,  rfile);  {  file  name,  since  this  will  be  assigned  by  the  } 

j  :=  READ_FILE(  1,  1,  rfile);  {  writing  module.  } 

FILE  SEEK(  j,  rfile); 
j  :=  READ_FILE(  1,  1,  rfile); 

FILE  SEEK(j,  rfile); 
headCT_crc  :=  READ_FILE(  1,  2,  rfile); 
if  head»_crc  >  0  then  begin 
for  i  :=  0  to  3  do 

header  cre  header  cre  +  mail  num[i]; 

FILE_SEK( -2,  rfile); 

WRrre_FILE(  header__crc,  2,  rfile); 
end; 

CLOSE_FILE(  file_name); 
end; 

fran  WATT  to  same 
fdien  cc.delete_bulletin 
be^ 

DECREMENT_MSG(  "BULLETIN",  mail_head,  firstjet); 
end; 
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firom  WAIT  to  same 
when  cc.puise_inail 

bc^ 

if  not  all  then  begin 

if  to  ttien  b^in  {  Puige  all  messages  ’to’  a  certain  callsign, 

file.name  :  =  GET_FIRST_FILE(  date,  en^jstrtng); 
while  file_name  <  >  empty  ^string  do  b^h 
if  MSG_TC)(  callsign)  then  be^ 
if  p^_time  >  0  thm  begin 

rfilc  :*  OPEN_HLE(  file  name); 

FILE  SEEK(  itf,  rfile): 

ul^timc  :*  READ_FILE(  I,  4,  rfile); 

CLOSE_FILE(  file_name); 
if  ul_time  <  p(^_time  then  begin 
DELETE_FILE(  file_name); 

DECR£MENT_MSG(  file_name[2..7),  mail_head,  first_let); 
end; 
end; 

dse  begin 

DELETE_FILE(  file_naine); 

DECREMENT_MSG(  file_name[2..71,  mail_head,  firstjet); 
end; 
end; 

file_name  :=  GET_NEXTJFILE(  date,  filejiame); 
end; 
end; 

else  if  from  then  begin  {  Purge  all  messages  ’from’  a  certain  callsign. 
sname[0..1]  :=  "  "; 
sname[2..7]  callsign; 

file_name  :  =  GBr_FIRST_FILE(  name,  sname); 
while  file_name  <  >  empty  jstring  do  begin 
if  post_time  >  0  then  begin 

rfile  :  =  OPEN  FILE(  file_name); 

FILE_SEEK(  w,  rfile); 

ul_time  :=  READ_FILE(  1,  4,  rfile); 

CLOSE_FILE(  file_name); 
if  ul^time  <  post_time  then  begin 
DELETE_FILE(  file_name); 

DECREMENT_MSG(  callsign,  mail_head,  first_let); 
end; 
end; 

else  begin 

DELETE_FILE(  file_name); 

DECREMENT_MSG(  callsign,  mail_head,  firstjet); 
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file^mne  :»  QET_NEXT_FILE(  none,  file_naiiie); 


mAt 

eke  be^  {  Purge  ell  messages.  ) 

ffie.iuuiie  :«  GET_FIRST_FILE(  date,  empty  jtring)  ; 
ei&file  name  <  >  en^  jrri^dobe^ 

It  filejiame(p..7]  <  >  BULLETIN* 

•ad  ^juune[0..7]  <  >  "USRTELEM*  thoi  begin 
tf  p(M  time  >  Otbeib^bi 

ifiie  OPEN  FILE(  file  name); 

HLE  SEEK(  lit,  ifile); 

ul  time  :»  READ  FIL£(  1,  4,  rfile); 

CLOSE_FILE(  file'name); 
if  ul_time  <  post_tiine  then  begin 
DELETE  FILE(  file  name); 

DECREMENT^MSdi:  file_name[2..7],  maa_head,  firstjet); 

end; 

Old; 

dsebe^ 

DELETE_FILE(  file^name); 

DECREMENT_MSG(  file_naine[2..7],  mail^head,  firstjet); 
end; 

Old; 

file_name  :=  GET_NEXT_F1LE(  date,  file_namc); 

end; 

end; 

end; 

aid; 


169 


ftroD  WATT  to  saoie 
whoa  ts.stoie_usr_telan 

bc^ 

INCREMENT_MSG(  "USRTELEM*.  next_souice_num,  maU.head,  first.tet, 
mailjium,  ext); 

rfUe  OPEN_FILE(  tdon);  {  File  has  already  been  created  and  written  by  the  } 
FILEJSEEK(  mR»  rfile);  {  telraietry  module.  Here,  we  just  keep  track  } 
WRrrE_FILE(  niail_num,  4,  riile);  {  of  how  many  usr  tdon  files  are  active,  and  } 
FILE_SEEK(  -  ni/,  rfile);  {  write  appropriate  mail_number  into  the  file  } 
num_dest R£AD_FILE(  1,  1,  rfile);  {  header.  In  this  case,  the  mail_number  } 
if  num_dest  >  0x07  Uwn  {  will  not  accurately  reflect  the  extension  of  the} 

FILE_SEEK(  42,  rfile);  {  file  name,  since  this  will  be  assigned  by  the  } 

j  READ  FILE(  1,  1,  rffle);  {  writing  module.  } 

FILE  SEEI^j,  rfUe); 
j  :=  READ  FILE(  1,  1,  rfile); 

FILE_SEEK(j,  rfile); 
head»_crc  :=  READ_FILE(  1,  2,  rfile); 
if  headerjcrc  >  0  then  begin 
f or  i :  s  0  to  3  do 

header_crc  :  =  header  crc  +  mail_num[i]; 

FILE_SEEK( -2,  rfile); 

WRriE_FILE(  headerjcrc,  2,  rfile); 
tndi 

CLOSBJFlLEi  telem); 

end; 

from  WATT  to  same 

when  ts.delete_user_telem  {  Telemetry  module  has  already  deleted  the  file  and  } 

begin  {  is  only  notifying  the  mail  box  module.  } 

DECREMENT_MSG(  "USRTELEM",  maU_head,  firstjet); 
end; 

I;  {  ofMAILBOX_CONTROL_BODY  } 


I 


1 1 1 1 1 1 1 1 1 1 


FASSWOBD.CONITOL.BCX)  Y  fir  PASSWCMtD.CONTRQL.TYPE;  a^tcnni; 
AUTOLCOinitOL.BC»>Y  for  AinOJXnmOLJTYPE;  cxicml; 

GROUND.CONTROL.BODY  for  QROUND_CONTR(»L.TYPE;  cartcnnl; 
FRlMrnVE.SW_LOADER  for  PRIMmVE.SW.LOADER.TYPE;  cxtcmol; 
TELEMETRY_GATHER_BODY  for  TELEMETRY.GATHERJTYPE;  cxtomol; 


A/D_DRIVER_BODY  for  A/D_DRIVERjrYPE;  external; 

EVENT_LOGGER_BODY  for  EVENT_LOGGER_TYPE;  external; 

EPS_DRIVER_BODY  for  EPS_DRIVER_TYPE;  external; 

COMM_DRIVER_BODY  for  COMM_DRIVER_TYPE;  external; 

DCS_DRIVER_BODY  for  DCS_DRIVER^TYPE;  external; 
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{Module  iMtantfaition  and  dannei  connection  } 
BMdear  {  aectkm  for  Flii^t  Software  Specification.  } 

Primitive  AX25:  PRIMITIVE  AX2S  TYPE; 

PrimitivelSW.Looder:  PIUMrnVE_SW_LbADER_TYPE; 

Data_Tnnsfer:  DATA_TR/5lSI^_TYPE;” 

Packet  Tnmsfer.  arrayCmocfiiikr]  of  PACKET  TRANSFER  TYPE; 
Mailbm.Contiol:  MAILBOX_CONTROL_TYPE; 

GioundJControl:  GROUND jcONTROLJTYPE; 

Auto_CmtrQl:  AUTO_cdNTROL_TYPE; 

EveaT  Logger  EVENT  LOGGER 'TYPE; 

Passe^_C(ntrol:  PASSWORD.CONlltOL.TYPE; 

Telonetry  Gather  TELEMETRY  GATHER~TYPE; 

A/D  Drivw:  A/D  DRIVER'tYPE; 

EPS  Driver  EPS.DRIVER'TYPE; 

Comm  Driver:  COMM_DRIVER_TYPE; 

DCS_Mvcr:  DCS_DRIVER_TYPE; 

initialiae  { Initialization  Part  of  the  Specification  } 

begin 

init  Primitive  AX25  with  PRIMITIVE  AX25  BODY; 

Init  Primitivelsw  Loader  with  PRIMnWE  SW  LOADER  BODY; 

init  Data  Transfer" with  DATA  TRANSFER" BODY; 

init  Mailtox  Control  with  MaLbOX  CONTROL  BODY; 

init  Ground  Control  with  GROUND  CONTROL  BODY; 

init  Auto  C^trol  with  AUTO  CONlltOL  BODY; 

init  Event  Logger  with  EVENT  LOGGER"bODY: 

init  Password  Control  with  PASSWORD  CONTROL  BODY; 

init  Tclciiietryl.Gather  with  TELEMETRY_GATHER" BODY; 

init  A/D  Driver  with  A/D  DRIVER  BODY; 

init  EPSiDriver  with  EPSJDRIVER"bODY; 

init  Comm  Driver  with  COMM  DRIVER_]^DY; 

init  DCS_Mver  with  DCS_DRiVER_BODY; 

all  link:  LinkJType  do  be^ 

init  PackttJTransferpink]  with  PACKET_TRANSFER_BODY; 
connect  Data_Transfer.pc[link]  to  Packet_Transfei(linl0.pc; 
connect  Mailbox_Control.mc[link]  to  Packet_Transfer[]ink].nic; 
connect  Event_L^er.d[link]  to  Packet_Transfer[link].el; 
rad; 

cranect  Primitive_AX2S.bax[0]  to  DataJTransfer.hax; 
connect  Primitive_AX2S.bax[l]  to  Grov^.Conttol.bax; 
connect  Primitive_AX2S.bax[2]  to  Auto_Control.bax; 
cranect  Primitive_AX25.bax[3]  to  Primitive_SW__Loader.bax; 
cranect  Giound_Oontrol.ccd  to  DataJTransfer.cc^]; 
connect  Gtrand^Control.cct  to  Tdemetry^Gathm-.cclO]; 
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liiiiliiUlliliilliiil 


CkBWtfjOoiMraLeGi  to  Mmitive.SWJLoitor.ocfO]; 
QnMtojC2oitoQl.oep  to  FnmfoidjCaotiol.oc(p]; 
GrawMl.Coatvol.ocm  to  ltoiBMK.CQiitvol.ocfO]; 
GrawMlICoatiol.ooe  to  EPS.Drim.ocfQ]; 
Gvowid.Caotvol.ooora  to  Coaun.Dtiver.ocfO]; 
Groiind.Coatrol.oodc  to  DCS.E^wer.ocfO]; 
Gvound.Caiitrol.d  to  Event.Loifer.eifmadiMb]; 
GvoinMl.Coatvol.K  to  Aulo_Coolrol.sc; 
Aiao.Coatvd.iod  to  Data.Tnmsfer.ocfl]; 
Aim>_Cootid.ict  to  Tdemetry.Gatlier.ocil]; 
Aiao_Coatrol.aG|>  to  Fmswocd.Control.odl]; 
Aulo_Coatrol.icm  to  Itoilbox.Control.ocfl]; 
AinD.Coatid.aoe  to  EPS.Driver.odl]; 
Aulo.CQOtid.ioora  to  CmnmJ)river.cc{l]; 
Auto.Contrd.aodc  to  DCS.XMver.ccfl]; 
AinD.Cootrd.d  to  Event.Logga.  dfmc^Mb  +  1]; 
Tdemetiy.Gather.ad  to  AD^Driver.ad; 
Tdemetry.Gather.d  to  EvenTLog.dlffMxciinib  +  2]; 
Tdenietiy_GaBier.ts  to  Mailbox^Control.ts; 
Itoilbox_Contid.d  to  Event.Logger.d[mac/inib  +  3]; 
Data.Ttonsfer.d  to  Event Jjogger.dlmodmib  +  4]; 
Psssword.Contrd.d  to  Event.Loggor.d[max/iito  +  5]; 


cod.  { of  Flight  Software  Specification  } 
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APPENDIX  B  -  DATA  PLOW  DIAGRAMS 

DFD:  CONTEXT  DIAGRAM 
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DFD  1  -  Communications  k 

File  Transfer  Software 
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DFD  3  -  Satellite  Hardware  Control 
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DFD  1.4  -  Mailbox-Control  Module 

Response  to  Messages 


APPENDIX  C  •  ESTELLE  SYNTAX 


Tride  C.l  oontaiiis  Ihe  sidMet  of  Fucal  syntax  which  was  utilized  in  ^ipeiidix  A. 
Note  dat  odb  with  double  lines  on  top  and  bottom  contain  definitions  someudiat 
motfified  ftom  dioee  found  in  [Ref.  8].  A  mcne  con^dete  lexicon  and  constru^ion  rules 
can  be  found  in  Annex  C  of  [Ref.  8]. 

Key: 

1)  Eadi  dilution  ends  with  a  period,  . 

2)  The  or  symbd,  *  | ",  denotes  a  choice  among  (^ticms. 

3)  Components  enclosed  by  square  brackets,  *[  ]”,  are  optional. 

4)  Parentheses,  *(  )*,  are  used  for  grouping  compcments  in  order  to  clarify  definitims. 

5)  Onnpooents  enclosed  by  curly  brackets,  "{  may  be  included  zero  or  more  times. 
Q  Symbcds  shown  within  quotes, "  ",  must  be  typed  mcactly  as  they  appear.  (They  will 
be  found  in  b<M-foce  fype  within  the  specification.) 


TABLE  C.l  PASCAL  SYNTAX  USED  IN  APPENDIX  A 


letter  »  "a"  j  "b" 

1  ...  1  "z"!  "A"  1  - 

•B" 

"Z". 

digit  -  "0"  1  "1" 

1  .2-  1  -3-  1  -4"  1 

"5* 

’  1  "6" 

1  "C"  1  "D"  1  "E" 

JJ 

T". 

qpedal-symbol 

1  ***  1  1  ^ 

1  •<" 

1  ">"  1  "["  1  -1"  1  -("  1  T  1 

m.m  1  aAii  |  ^ 

1  • 

’<="  1 

1  ->=-  1  1  1 

word-symlwl. 
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_ _ TABLE  C.1  PASCAL  SYNTAX  USED  IN  APPENDIX  A 

wont-symbol  >■  "and*  |  "arny"  |  "be^*  |  *case*  |  "const"  |  "do"  |  "downto" 

I  "dsc"  I  "end"  |  "firisc"  |  "for"  |  "function"  |  "iP  |  "in"  | 
"not"  I  "nuU"  I  "oP  |  "or"  |  "procedure"  |  "reconI"  | 
"iq)eat"  |  "tiien"  |  "to"  |  "true"  1  "type"  |  "  until"  |  "var"  | 
"while". 

ktentifier  »  letter  {  letter  (  digit }. 
unsigned-integer  «  digit  (digit}  |  "Ox"  digit  {digit). 

character-string  »  *  *  *  string-character  {  string-character  }  "  *  _ 

comment  »  "{"  any-sequence-of-characters-and-sqnrations-of-lines-not- 
_ ccmtaining-right-brace  "}". _ 

block  s  constant-derinition-part 

type-definiti(Mi-part 
variable-declaration-part 
procedure-and-functitm-declaration-part 

_ statement-part. _ 

constant-definition-part  -  [  "const"  constant-definition  ";"  {  cmistant-derinition 

_ ru _ 

type-definition-part  =  [  "type"  type-definition  ";"  {  type-definition  ";"  }  ]. _ 

variable-declaration-part  =  [  "var"  variable-declaration  {  variable-declaration 

_ }  ]■ _ _ 

procedure-and-function-declaiation-part  =  {  (  procedure-declaration  {  fiinction- 
_ declaration  )  ";"  }. _ 

statement-part  =  compound-statement. _ 

constant-definition  =  identifier  *="  constant. _ 

constant  =  [sign]  ( unsigned-integer  |  constant-identifier )  |  character-string. 

constant-identifier  =  idwitifier. _ 

type-definition  ==  ittoitifier  "«"  type-d«ioter. _ 

type-denoter  =  ordinal-type  |  new-type. 

new-type  ~  new-ordinal-type  |  new-structured-type  {  new-pointm’-type. 
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IN 

IX 

TABLE  C.1  PASCAL  SYNTAX 


structured-type-identifier  »  type-ktendHer. 


pointer-type-identifier  >  type-identifier. 


type-identifier  iden^ 


oedinal-type  «  new-oidinal-type  |  <»dinal-type-identifier. 


new-oidiml-type  «  enumerated-type  j  subrange-type. 


onlinal-type-identifier  *  udiar  |  uint  |  ulong  |  int  |  boolean. 


udhar  >  S-bits-binaiy-data-or-l-byte-unsigned-integer-or-l-ascii-diaiacter. 


uint  2-byte-unsigned-int^er. 


ulong  «  4-byte-unsigned-int^er. 


int  [sign]  unsigned-int^er. 


sign 


"true"  I  "false". 


enumerated-type  -  "("  identifier-list  ")". 


identifier-list  ==  identifier  (  ","  identifier  ). 


subrange-type  =  omstant  ".."  constant. 


structured-type  «  new-structuied-type  |  structured-type-identifim’. 


structured-type  «  array-type  |  record-type. 


array-type  =»  "array"  "["  number-components  "]"  {  "["  numbo’-components  "]"  } 
"or  ccmiponent-type. 


number-conqKments  unagned-int^er. 


conqponent-type  »  type-denoter. 


rec(xd-type  »  "record"  field-list  "end". 


fidd-list  »  recmd-section  { ";"  record-section  }. 
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TABLE  C.1  PASCAL  SYNTAX  USED  IN  AFPENDK  A 

reooni*3ectioii  »  identifier-list  *:*  typeslenoter. 

pointer-type  »  new-pointer-type  |  ptrater-type-identifier. 

new-pointer-type  »  type-identifier. 

variable-declaration  »  identifier-list  *:*  type-d»)oter. 

variable-access  »  entire-variable  |  compcment-variable  |  idoitified-vaiiable. 

entire-variable  »  variable-identifior. 

vari^le-identifier  =  identifier. 

component-variable  —  indexed-variable  |  field-designator. 

indexed-wiable  «  anay-variable  *[*  index-expression  "]*  {  index-expression 

T ). 

array-variable  =  variable-access. 

index-expression  =  expression. 

field-designator  =  record-variable  field-specifier  |  field-identifier. 

record-variable  =  variable-access. 

field-qiecifiCT  =  field  idoitifier. 

fidd-idoitifier  =  identifier. 

identified-variable  ~  pointer-variable. 

pointCT-variable  =  variable-access. 

procedure-declaration  -  procedure-heading  directive 

1  procedure-identification  procedure-block 

1  procedure-heading  procedure-block. 

procedure-heading  =  "procedure"  identifier  [  formal-parameter-list  ]. 

IHOcedure-identificati<m  ==  "procedure"  |nx)cedure-idoitifier. 

procedure-idoitifier  identifier. 

procedure-block  =  block. 
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TABLE  C.1  PASCAL  SYNTAX  USED 


fun^km-dedaratioii  »  function-heading  directive 

I  function-identification  function-block 
_ i  function-heading  function-block. 


functioo^ieading  »  "function*  identifier  [  fOTmal-paramrter-list  ]  result-type. 

function-identifkation  »  "function*  function-identifier. _ 

function-identifier  ==  identifier. _ 

functioo-block  »  block. _ 

result-type  «  ^pe-denote. _ 

formal-parameter-list  =  ”("  formal-parameter-section  {  formal-parameter- 
section  }  ")*. 

formal-parameter-section  -  value-parameter-specification 

variable-parameter-qMdfication. 

value-param^er-i^tecificatiCTi  =  identifiCT-list  *:*  type-idoitifier. _ 

variable-param^-q>ecification  =  "var"  identifier-list type-i<toitifier. _ 

express wi  «  simple-expression  [  relational-operator  simple-expression  ]. _ 

simple-expression  =  [sign]  term  {  adding-operator  term  }. _ 

term  »  factor  {  multiplying-operator  factor  }. 

factor  »  variable-access  |  unsigned-ccmstant  |  function-designator  | 
_ set-constructor  |  "("  expression  ")"  |  "not"  factor. _ 

unsigned-constant  =  unsigned-number  |  character-string  |  constant-identifier  | 
_ "null". _ 

s^-constructor  =  "["  [  member-designator  {  ","  membCT-designator  }]"]". 

member-designator  »  expression  [ ".."  expression  ]. _ 

multiplying-operator  =  "♦"  {  "and". _ 

adding-opCTator  «  "■>•"  |  "-"  \  "or". _ 

relational-operator  =  "»"  ("<>"}  "<*  |  ">"  |  ■<="  }  *>="  |  "in". 

bodean-mcpiession  »  expression. 
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TABLE  C.1  PASCAL  SYNTAX  USED  IN  APPENDIX  A 

functioii-desigiutCMr  »  fiuictim-identifier  [  actual-parameto’-list  ]. 

actual-panuneter-list  »  ”(*  actual-paiameter  {  *,*  actual-parameter  } 

actual-parameter  »  expression  |  variable-access  |  procedure-identifia'  | 
function-identifier. 

statement  »  (  simple-statement  {  structured-statement ). 

simple-statraient  »»  empty-statement  |  assignment-statement  i 
proc^ure-statement. 

empty-statemoit  «  . 

assignment-statement  =  ( variable-access  {  function  identifier )  expression. 

procedure-statement  =  procedure-idoitifier  ( [  actual-parameter-list  ] ). 

structured-statement  =  compound-stateh^t  |  conditional-statemoit  | 
repetitive-statement. 

statement-sequoice  =  statement  {  *;"  statement }. 

compound-statement  =  "begin"  statemoit-sequence  "aid". 

conditional-statement  =  if-statement  |  case-statemoit. 

if-statement  »  "iP  boolean-expression  "then"  statement  [  else-part  ]. 

else-part  =  "else"  statemoit. 

case-statement  =  "case"  case-index  "oP  case-list-element  {  ";"  case-list-element  } 

[  ";"  ]  "end". 

case-list-elemoit  case-constant-list  ":"  statement.  | 

case-constant-list  =  case-constant  {  ","  case-constant }.  | 

case-ccmstant  =  constant. 

case-index  =  expression. 

lep^tive-statement  ~  repeat-statement  |  while-statement  |  for-statement. 

rqieat-statement  =  "rqieat"  statement-sequoice  "until"  boolean-expression. 

while-statement  =  "while"  boolean-expression  "do"  statement. 
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TABLE  C.1  PASCAL  SYNTAX  USED  IN  APPENDIX  A 


ftw-Aatement  "for”  control-variable  initial-value  ( ”to"  |  "downto" ) 
_ final-value  "do*  statement. 

contnd-variable  »  entire-variable. _ _ 

initial-value  »  expression. _ 

final-value  »  expression. 


The  ftdlowing  table  lists  Estelle-!9)ecific  rested  words  which  have  been  used  in 


Appendix  A.  The  expected  location  and  functitm  associated  with  each  is  also  indicated. 


1  TABLE  ESTELLE-SPECmC  RESERVED  WORDS 

Reserved 

Word 

Location 

Function 

q;wcification 

Beginning  of  entire 
specification  block. 

Identifies  the  name  of  the 
specification. 

any 

In  a  constant  declaration. 

Declares  that  a  value  of  the  indicated 
type  must  be  chosen  during 
implementation. 

•  • 

By  itsdf,  on  the  right- 
hand  side  of  a  type 
definition. 

Indicates  that  the  actual  internal 
details  of  the  type  have  not  yet  been 
determined.  The  final  definition  may 
be  implementation-dq)endant. 

channel 

In  the  channel  definition 
section,  which 
immediately  follows  the 
global  constant,  type  and 
and  variable  declaration 
secticms. 

Indicates  the  beginning  of  a  channel 
definiti(Hi.  Followed  by  the  channel 
name,  and  then,  within  parentheses, 
the  «id-point  names. 
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TABLE  CJ 


WORDS 


2I2TI^^2S223EI^S32S 


ReMTed 

Word 

Location 

Fbnctlou 

by 

Within  a  duumel 
definition. 

'by*  is  followed  by  one  of  the 
duumel  end  point  names  and  then  by 
a  list  of  the  messages  which  can  be 
sent  ftom  that  end  point.  Following 
each  message  name,  in  parentheses, 
is  a  list  of  the  parameters  for  that 
message  type. 

module 

In  the  module  header 
definition  section,  which 
follows  the  global 
function  and  procedure 
declarations  which  follow 
the  diannel  definition 
section. 

Indicates  the  beginning  of  a  module 
header  definition,  "module"  is 
followed  by  the  name  of  the  module 
type.  The  module  header  definition 
defines  the  interfaces  with  the  module. 

systnn 

IMtwess 

In  the  module  header 
definition  following  the 
name  of  the  module  type. 

Indicates  that  the  module  is  an 
autonomous  process,  not  a  subprocess 
enclosed  within  another. 

*P 

In  the  module  header 
definition. 

Indicates  the  beginning  of  the  list  of 
interface  points  for  the  module.  It  is 
followed  by  the  channel  names,  each 
of  which  is  given  a  channel  type  from 
among  those  defined  in  the  channel 
definition  section.  In  parentheses  is 
indicated  which  end  point  this  module 
plays  the  role  of.  That  in  turn, 
detines  the  type  of  messages  which 
can  be  sent  by  this  module. 

individual 

queue 

In  an  interface  point 
declaration  within  a 
module  header  definition. 

Indicates  that  all  messages  to  or  from 
this  module  via  the  indicated  channel 
will  be  maintained  in  an  individual 
queue  for  that  module  alone. 
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1  TABLE  C.2  ESTELLE-SFECmC  RESERVED  WORDS  | 

Roorred 

Word 

Location 

Function 

coBumon 

queue 

In  an  interftce  point 
declaration  within  a 
module  header  definition. 

Indicates  that  the  module  will  share 
the  queue  for  diis  channel  with  all 
other  ‘conunon  queue"  modules 
playing  the  role  of  the  same  land  of 
end  point  for  the  same  kind  of 
channel.  Or,  if  a  module  has  an 
array  of  channels  of  the  same  type, 
all  of  the  channels  may  use  a 
conunon  queue. 

body 

In  the  module  body 
definition  section,  which 
follows  the  module 
header  definition  section. 

Indicates  the  beginning  of  a  module 
body  definition.  This  is  where  the 
actual  behavior  of  the  module  is 
defined. 

external 

In  the  module  body 
definition  section, 
following  the  body  name 
and  the  module  type. 

Indicates  that  the  body  definition  for 
this  module  is  external  to  the  current 
specification.  It  may  not  yet  have 
been  developed,  may  be  under 
development  by  another  team,  or  it 
may  be  completely  external  to  the 
system  at  hand,  with  only  the 
interface  defined  by  the  module 
header  definition  b^g  of  any 
importance. 

state 

Within  a  module  body 
definition,  following  the 
local  const,  type  and  var 
declaration  sections. 

Marks  the  beginning  of  the  list  of 
state  names  for  this  module. 
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TABLE  ESTELLE-SFECmC  RESERVED  WORDS 


Rewnred 

Word 

Location 

function 

statcset 

Within  a  module  body 
definition,  following  tlw 
list  of  state  names. 

Defines  a  comnum  name  to  be  used 
for  several  states,  when  they  have 
similar  transitions.  If  the  module 
state  machine  reacts  the  same  way  to 
a  particular  stimulus  when  in  any  one 
of  several  diffoent  states,  these  states 
may  be  grouped  together  by  a  stateset 
so  that  the  b^vior  need  only  be 
written  out  once  for  all  the  affected 
states. 

primitive 

In  a  function  or  procedure 
declaration. 

Indicates  that  the  algorithmic  details 
of  the  function  or  procedure  are  not 
included  in  the  present  specification. 

The  function  or  procedure  may  be 
deemed  to  be  commonly  understood 
or  readily  available  from  the  operating 
system,  or  the  details  may  simply  not 
be  relevant  to  the  aspect  of  the  system 
currently  under  consideration. 

initialize 

Following  the  last  local 
function  or  procedure 
declaration  within  a 
module  body  definition. 

Indicates  the  initial  state  of  the 
module  state  machine  when  it  is 
instantiated.  Statements  between  the 
”b^in"  and  "end"  keywords  may  be 
used  to  set  up  initial  variable  values, 
and  to  take  any  other  automatic  "start¬ 
up"  actions. 

trans 

Following  the 
initialization  section  in 
the  module  body 
definition. 

Indicates  the  beginning  of  the  state 
transition  section  of  the  module  body. 
All  possible  state  transitions  will  be 
listed  within  this  section. 

fran 

In  the  transition  section  of 
the  module  body 
definititHi. 

Indicates  the  state  from  which  the 
transition  takes  place. 

TABLE  CJt  ESTELLE-SPECmC 


WORDS 


Word 


Locathm 


In  the  transition  aectitm  of 
the  module  body 
definition. 


Following  the  "fitm  - 
to"  clause  of  the 
transition  statement. 


Following  the  "when" 
clause  of  the  transition 
statement. 


Function 


Indicates  the  state  in  which  the 
nuxlule  will  be,  following  the 
transition. 


Identifies  the  stimulus  which  may 
trigger  the  transititm.  "when"  is 
usually  followed  by  the  name  of  an 
interface  point,  with  a  period,  ".", 
and  die  Idnd  of  message  from  that 
channel  which  could  trigger  the 
transition.  Any  parameters  associated 
with  the  incoming  message  may  be 
referenced  direcdy  by  their  value- 
parameter  names  within  the  "begin  - 
end"  block  of  the  transiticMi  statemoit. 


Indicates  any  further  conditions  for 
the  transition  to  occur,  ’pro-^ied’  is 
usually  followed  by  an  exprei  on  in 
which  one  of  the  paiameten  of  the 
"whra  message"  is  compared  with  a 
necessary  condition.  The  transition 
only  occurs  whm  the  module  is  in  the 
"from  state",  the  "when  message" 
arrives,  and  the  message  parameter 
meets  the  necessary  condition.  When 
the  transition  occurs,  all  of  the 
statements  between  "begin”  and 
"end”  are  executed  before  the  module 
enters  the  "to  state”  and  waits  for  the 
next  stimulus. 


TABLE  CJ  ESTELLE^FECinC  RESERVED  WORDS 


Rcsored 

Word 

Locatkm 

F^incthm 

Oll^Ut 

Within  the  "begin  •  aid" 
block  of  a  transition 
statement. 

Indicates  that  a  message  is  to  be  sent 
out  at  the  interface  point  indicated. 

The  interface  point  name  is  shown  on 
the  left  side  of  a  period,  with  the  type 
of  message  on  the  right  side.  If  thm 
are  any  message  parameters,  variables 
of  the  appropriate  types  must  be 
prqiared  wiA  the  proper  values,  and 
must  be  included  in  paroitheses 
following  the  message  name. 

modvar 

Following  all  module 
body  definitions. 

Indicates  the  b^inning  of  the  module 
instantiation  and  channel  connection 
section  of  the  specification. 

initialize 

In  the  modvar  section. 

Indicates  the  beginning  of  the  module 
instantiation  section,  which  will  define 
exactly  how  many  copies  of  each 
module  type  will  be  created,  using 
which  module  bodies. 

init 

In  the  module 
instantiation  section. 

"init”  indicates  initialize,  but  really 
means  instantiate.  Use  the  module 
body  indicated  by  the  "with”  clause, 
(there  could  be  more  than  one  module 
body  for  a  particular  module  type). 

connect 

In  the  modvar  section, 
following  the  module 
instantiations. 

Indicates  that  the  interface  points  of 
two  modules  will  be  connected 
together.  Further  defines  which 
specific  channels  go  between  which 
specific  module  instantiations. 
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